aspirant
|
Date: 1/20/2011
|
|
|
|
|
Mikhail Sukhov:
[*]```
_sections[_sectionNames.IndexOf(sectionName)];
> Лучше проверить через Contains.
> [*]```
try
{
....
}
catch (KeyNotFoundException ex)
{
throw new KeyNotFoundException(String.Format("Неопознанный раздел конфиг-файла: {0}", sectionName), ex);
}
Старайтесь минимизироваться перехват исключений. В том случае это решается через простую проверку на существование в коллекции.
Большинство комментариев относится ко мне. Все поправил за исключением верхнего куска. Вот мое мнение: давно на каком-то MS'ском блоге читал рекомендацию: если в большинстве случаев ключи будут находиться, лучше сразу возвращать значение через метод this[TKey key] и перехватывать неопознанные ключи через исключение. Если вероятность исключения велика, лучше это делать через метод Contains. Это кусок кода написан в protected методе, к которому обращается только мой плазовский код. Входящие значения ключей заранее известны и контролируются, т.е. вероятность ненахождения ключей мала.
Михаил, за вами, как за менеджером проекта, последнее слово.
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 1/20/2011
|
|
|
|
|
aspirant:
Большинство комментариев относится ко мне.
Потому что другие пока код с логикой не писали. Вот сейчас начнут, и будут комментарии к другим.
aspirant:
Mikhail Sukhov:
[*]```
_sections[_sectionNames.IndexOf(sectionName)];
> > Лучше проверить через Contains.
> > [*]```
try
{
....
}
catch (KeyNotFoundException ex)
{
throw new KeyNotFoundException(String.Format("Неопознанный раздел конфиг-файла: {0}", sectionName), ex);
}
Старайтесь минимизироваться перехват исключений. В том случае это решается через простую проверку на существование в коллекции.
Вот мое мнение: давно на каком-то MS'ском блоге читал рекомендацию: если в большинстве случаев ключи будут находиться, лучше сразу возвращать значение через метод this[TKey key] и перехватывать неопознанные ключи через исключение. Если вероятность исключения велика, лучше это делать через метод Contains.
Тут не столько дело в перехвате и в Contains, сколько в сложности конструкции ```
_sections[_sectionNames.IndexOf(sectionName)];
Еще раз посмотрел. А почем бы сразу было не сделать Dictionary?
> **[aspirant](@message(5540)):**
> Это кусок кода написан в **protected** методе, к которому обращается только мой плазовский код. Входящие значения ключей заранее известны и контролируются, т.е. вероятность ненахождения ключей мала.
Насчет модификаторов доступа. Есть подозрение что они неправильно используются. Можете привести их описание применительно к случаям использования - когда какой использовать?
|
|
|
|
Thanks:
|
|
|
|
|
|
aspirant
|
Date: 1/20/2011
|
|
|
|
|
Mikhail Sukhov:
Тут не столько дело в перехвате и в Contains, сколько в сложности конструкции ```
_sections[_sectionNames.IndexOf(sectionName)];
> Еще раз посмотрел. А почем бы сразу было не сделать Dictionary?
Вы правы: что я действительно здесь намудрил. Сегодня сведу все в Dictionary.
> **[Mikhail Sukhov](@message(5541)):**
> > **[aspirant](@message(5540)):**
> > Это кусок кода написан в **protected** методе, к которому обращается только мой плазовский код. Входящие значения ключей заранее известны и контролируются, т.е. вероятность ненахождения ключей мала.
>
> Насчет модификаторов доступа. Есть подозрение что они неправильно используются. Можете привести их описание применительно к случаям использования - когда какой использовать?
protected может использоваться только классами-наследниками, ну и самим классом тоже. Снаружи он не виден. Я имел в виду, что у меня есть класс ConfigParser. От него наследует класс ClientRouterConfigParser, который и запрашивает информацию, передавая ключи.
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 1/20/2011
aspirant:
protected может использоваться только классами-наследниками, ну и самим классом тоже. Снаружи он не виден. Я имел в виду, что у меня есть класс ConfigParser. От него наследует класс ClientRouterConfigParser, который и запрашивает информацию, передавая ключи.
Все ок. Я не увидел наследования. Но все равно, на будущее. Стиль именования протектем полей такой же как и паблик. Потому как смысл у них почти одинаковый.
|
|
|
|
Thanks:
|
|
|
|
|
|
aspirant
|
Date: 1/21/2011
aspirant:
Mikhail Sukhov:
Тут не столько дело в перехвате и в Contains, сколько в сложности конструкции ```
_sections[_sectionNames.IndexOf(sectionName)];
> > Еще раз посмотрел. А почем бы сразу было не сделать Dictionary?
>
> Вы правы: что я действительно здесь намудрил. Сегодня сведу все в Dictionary.
Только что закоммитил исправленный файл с классом ConfigParser. Идея такова: это базовый класс, который умеет парсить конфиг-файлы в формате Плазы. Для каждого конфиг-файла создается класс-наследник, который в своем конструкторе заполняет массив SectionNames списком возможных ключей для этого файла. Пока я только создал класс ClientRouterConfigParser, который настраивает главный конфиг-файл роутера Плазы client_router.ini. Я пока не разобрался, нужно ли будет настраивать другие конфиги.
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 1/21/2011
aspirant:
Только что закоммитил исправленный файл с классом ConfigParser. Идея такова: это базовый класс, который умеет парсить конфиг-файлы в формате Плазы. Для каждого конфиг-файла создается класс-наследник, который в своем конструкторе заполняет массив SectionNames списком возможных ключей для этого файла. Пока я только создал класс ClientRouterConfigParser, который настраивает главный конфиг-файл роутера Плазы client_router.ini. Я пока не разобрался, нужно ли будет настраивать другие конфиги.
Это хорошо. Только зря вы убрали метод FindSection. Вообще лучше по максимуму переменные делать private и доступ к ним или через методы или через свойства. Лучше через методы, чтобы базовый класс делал базовую работу, а не просто отдавал свое состояние дочерним.
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 1/21/2011
Еще список того, что может пригодиться:
- ODE0�
можно писать короче:
var myNumber = myString.To<int>();
- ODE2�
можно писать короче:
if (arg.IsEmpty())
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 1/21/2011
_dataStream.StreamLifeNumChanged += new IP2DataStreamEvents_StreamLifeNumChangedEventHandler(OnStreamLifeNumChanged);
можно писать короче:
v_dataStream.StreamLifeNumChanged += OnStreamLifeNumChanged;
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 1/30/2011
if (MyEvent != null)
MyEvent();
Проверка на null - это правильно. Но на следующей строчке MyEvent может стать null (в другом потоке произошла отписка от события) и будет NullReferenceException. Решается через доп переменную:
var evt = MyEvent;
if (evt != null)
evt();
Если не создавать собственных делегатов (видимо равнение идет на Плазу, где они создаются автоматически, а не потому что так правильно), то запись будет короче:
MyEvent.SafeInvoke();
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 3/18/2011
int и Int32 - это алиасы. так же для bool и Boolean и т.д. Выражение вида:
if (type == typeof(bool) || type == typeof(Boolean))
эквивалентно:
if (type == typeof(bool))
|
|
|
|
Thanks:
|
|
|
|
|