aspirant
|
Дата: 20.01.2011
|
|
|
|
Mikhail Sukhov  Code_sections[_sectionNames.IndexOf(sectionName)]; Лучше проверить через Contains.
Codetry { .... } catch (KeyNotFoundException ex) { throw new KeyNotFoundException(String.Format("Неопознанный раздел конфиг-файла: {0}", sectionName), ex); } Старайтесь минимизироваться перехват исключений. В том случае это решается через простую проверку на существование в коллекции.
Большинство комментариев относится ко мне. Все поправил за исключением верхнего куска. Вот мое мнение: давно на каком-то MS'ском блоге читал рекомендацию: если в большинстве случаев ключи будут находиться, лучше сразу возвращать значение через метод this[TKey key] и перехватывать неопознанные ключи через исключение. Если вероятность исключения велика, лучше это делать через метод Contains. Это кусок кода написан в protected методе, к которому обращается только мой плазовский код. Входящие значения ключей заранее известны и контролируются, т.е. вероятность ненахождения ключей мала. Михаил, за вами, как за менеджером проекта, последнее слово.
|
|
|
|
Mikhail Sukhov
|
Дата: 20.01.2011
|
|
|
|
aspirant  Большинство комментариев относится ко мне.
Потому что другие пока код с логикой не писали. Вот сейчас начнут, и будут комментарии к другим. aspirant  Mikhail Sukhov  Code_sections[_sectionNames.IndexOf(sectionName)]; Лучше проверить через Contains.
Codetry { .... } catch (KeyNotFoundException ex) { throw new KeyNotFoundException(String.Format("Неопознанный раздел конфиг-файла: {0}", sectionName), ex); } Старайтесь минимизироваться перехват исключений. В том случае это решается через простую проверку на существование в коллекции.
Вот мое мнение: давно на каком-то MS'ском блоге читал рекомендацию: если в большинстве случаев ключи будут находиться, лучше сразу возвращать значение через метод this[TKey key] и перехватывать неопознанные ключи через исключение. Если вероятность исключения велика, лучше это делать через метод Contains. Тут не столько дело в перехвате и в Contains, сколько в сложности конструкции Code_sections[_sectionNames.IndexOf(sectionName)]; Еще раз посмотрел. А почем бы сразу было не сделать Dictionary? aspirant  Это кусок кода написан в protected методе, к которому обращается только мой плазовский код. Входящие значения ключей заранее известны и контролируются, т.е. вероятность ненахождения ключей мала.
Насчет модификаторов доступа. Есть подозрение что они неправильно используются. Можете привести их описание применительно к случаям использования - когда какой использовать?
|
Автор топика
|
|
|
aspirant
|
Дата: 20.01.2011
Mikhail Sukhov  Тут не столько дело в перехвате и в Contains, сколько в сложности конструкции Code_sections[_sectionNames.IndexOf(sectionName)]; Еще раз посмотрел. А почем бы сразу было не сделать Dictionary? Вы правы: что я действительно здесь намудрил. Сегодня сведу все в Dictionary. Mikhail Sukhov  aspirant  Это кусок кода написан в protected методе, к которому обращается только мой плазовский код. Входящие значения ключей заранее известны и контролируются, т.е. вероятность ненахождения ключей мала.
Насчет модификаторов доступа. Есть подозрение что они неправильно используются. Можете привести их описание применительно к случаям использования - когда какой использовать? protected может использоваться только классами-наследниками, ну и самим классом тоже. Снаружи он не виден. Я имел в виду, что у меня есть класс ConfigParser. От него наследует класс ClientRouterConfigParser, который и запрашивает информацию, передавая ключи.
|
|
|
|
Mikhail Sukhov
|
Дата: 20.01.2011
aspirant  protected может использоваться только классами-наследниками, ну и самим классом тоже. Снаружи он не виден. Я имел в виду, что у меня есть класс ConfigParser. От него наследует класс ClientRouterConfigParser, который и запрашивает информацию, передавая ключи.
Все ок. Я не увидел наследования. Но все равно, на будущее. Стиль именования протектем полей такой же как и паблик. Потому как смысл у них почти одинаковый.
|
Автор топика
|
|
|
aspirant
|
Дата: 21.01.2011
aspirant  Mikhail Sukhov  Тут не столько дело в перехвате и в Contains, сколько в сложности конструкции Code_sections[_sectionNames.IndexOf(sectionName)]; Еще раз посмотрел. А почем бы сразу было не сделать Dictionary? Вы правы: что я действительно здесь намудрил. Сегодня сведу все в Dictionary. Только что закоммитил исправленный файл с классом ConfigParser. Идея такова: это базовый класс, который умеет парсить конфиг-файлы в формате Плазы. Для каждого конфиг-файла создается класс-наследник, который в своем конструкторе заполняет массив SectionNames списком возможных ключей для этого файла. Пока я только создал класс ClientRouterConfigParser, который настраивает главный конфиг-файл роутера Плазы client_router.ini. Я пока не разобрался, нужно ли будет настраивать другие конфиги.
|
|
|
|
Mikhail Sukhov
|
Дата: 21.01.2011
aspirant  Только что закоммитил исправленный файл с классом ConfigParser. Идея такова: это базовый класс, который умеет парсить конфиг-файлы в формате Плазы. Для каждого конфиг-файла создается класс-наследник, который в своем конструкторе заполняет массив SectionNames списком возможных ключей для этого файла. Пока я только создал класс ClientRouterConfigParser, который настраивает главный конфиг-файл роутера Плазы client_router.ini. Я пока не разобрался, нужно ли будет настраивать другие конфиги.
Это хорошо. Только зря вы убрали метод FindSection. Вообще лучше по максимуму переменные делать private и доступ к ним или через методы или через свойства. Лучше через методы, чтобы базовый класс делал базовую работу, а не просто отдавал свое состояние дочерним.
|
Автор топика
|
|
|
Mikhail Sukhov
|
Дата: 21.01.2011
Еще список того, что может пригодиться:
Codevar myNumber = Convert.ToInt32(myString); можно писать короче:
Codevar myNumber = myString.To<int>();
Codeif (string.IsNullOrEmpty(arg)) можно писать короче:
|
Автор топика
|
|
|
Mikhail Sukhov
|
Дата: 21.01.2011
Code_dataStream.StreamLifeNumChanged += new IP2DataStreamEvents_StreamLifeNumChangedEventHandler(OnStreamLifeNumChanged); можно писать короче: Codev_dataStream.StreamLifeNumChanged += OnStreamLifeNumChanged;
|
Автор топика
|
|
|
Mikhail Sukhov
|
Дата: 30.01.2011
Codeif (MyEvent != null) MyEvent(); Проверка на null - это правильно. Но на следующей строчке MyEvent может стать null (в другом потоке произошла отписка от события) и будет NullReferenceException. Решается через доп переменную: Codevar evt = MyEvent; if (evt != null) evt(); Если не создавать собственных делегатов (видимо равнение идет на Плазу, где они создаются автоматически, а не потому что так правильно), то запись будет короче: CodeMyEvent.SafeInvoke();
|
Автор топика
|
|
|
Mikhail Sukhov
|
Дата: 18.03.2011
int и Int32 - это алиасы. так же для bool и Boolean и т.д. Выражение вида: Codeif (type == typeof(bool) || type == typeof(Boolean)) эквивалентно: Codeif (type == typeof(bool))
|
Автор топика
|
|
|
Mikhail Sukhov
|
Дата: 08.05.2011
Подниму топик парочкой советов:
- internal на методы, свойста и поля (но не типа) в C# признак плохого дизайна. Говорит о том, что приосходит размытость границ логики.
-
CodeTrace.WriteLineIf(TracingLevel > 2, record.GetStrings().Join(";")); Плох тем, что не важно, есть необходимый уровень трассировки или нет, строчка будет собираться всегда. Если такая конструкция встречается в коде, который вызывается часто, может снизить производительность.
- Любите readonly. Тоесть, когда создаете поля, сразу их делайте readonly. Снять атрибут можно всегда. Но он предотвратит от нежелательной логики перетирания значения.
- Два кода абсолютно эквивалентны:
Codepublic class RootClass { private class NestedClass { internal int Prop { get; set; } } }
Codepublic class RootClass { private class NestedClass { public int Prop { get; set; } } }
|
Автор топика
|
|
|
aspirant
|
Дата: 08.05.2011
Mikhail Sukhov  Подниму топик парочкой советов:
- internal на методы, свойста и поля (но не типа) в C# признак плохого дизайна. Говорит о том, что приосходит размытость границ логики.
-
CodeTrace.WriteLineIf(TracingLevel > 2, record.GetStrings().Join(";")); Плох тем, что не важно, есть необходимый уровень трассировки или нет, строчка будет собираться всегда. Если такая конструкция встречается в коде, который вызывается часто, может снизить производительность.
Сделал криво, знаю. Уже думал над тем, чтобы переделать + поменять internal на public. В релиз не будет попадать вообще: выделю в отдельный метод с аттрибутом [Conditional("DEBUG")]
|
|
|
|
anothar
|
Дата: 09.05.2011
Добрый день. Если верить http://www.codeproject.com/KB/cs/WeakEvents.aspx, кот. ссылается на Ecma cпецификацию, то для обеспечения потокобезопасности делегатов необходимо еще и локирование: Code EventHandler eh; lock (this) { eh = MyEvent; } if (eh != null) eh(this, EventArgs.Empty);
|
|
|
|
aspirant
|
Дата: 27.05.2011
@esper, может выставишь у себя tab'ы (Tools \ Options \ Text Editor \ Tab \ Keep tabs)?
|
|
|
|
esper
|
Дата: 28.05.2011
aspirant  @esper, может выставишь у себя tab'ы (Tools \ Options \ Text Editor \ Tab \ Keep tabs)? Сделал
|
|
|