Tips n Tricks

Большинство комментариев относится ко мне. Все поправил за исключением верхнего куска. Вот мое мнение: давно на каком-то MS'ском блоге читал рекомендацию: если в большинстве случаев ключи будут находиться, лучше сразу возвращать значение через метод this[TKey key] и перехватывать неопознанные ключи через исключение. Если вероятность исключения велика, лучше это делать через метод Contains. Это кусок кода написан в protected методе, к которому обращается только мой плазовский код. Входящие значения ключей заранее известны и контролируются, т.е. вероятность ненахождения ключей мала.

Михаил, за вами, как за менеджером проекта, последнее слово.

Потому что другие пока код с логикой не писали. Вот сейчас начнут, и будут комментарии к другим.



Тут не столько дело в перехвате и в Contains, сколько в сложности конструкции
Еще раз посмотрел. А почем бы сразу было не сделать Dictionary?



Насчет модификаторов доступа. Есть подозрение что они неправильно используются. Можете привести их описание применительно к случаям использования - когда какой использовать?

Вы правы: что я действительно здесь намудрил. Сегодня сведу все в Dictionary.



protected может использоваться только классами-наследниками, ну и самим классом тоже. Снаружи он не виден. Я имел в виду, что у меня есть класс ConfigParser. От него наследует класс ClientRouterConfigParser, который и запрашивает информацию, передавая ключи.

Все ок. Я не увидел наследования. Но все равно, на будущее. Стиль именования протектем полей такой же как и паблик. Потому как смысл у них почти одинаковый.

Только что закоммитил исправленный файл с классом ConfigParser. Идея такова: это базовый класс, который умеет парсить конфиг-файлы в формате Плазы. Для каждого конфиг-файла создается класс-наследник, который в своем конструкторе заполняет массив SectionNames списком возможных ключей для этого файла. Пока я только создал класс ClientRouterConfigParser, который настраивает главный конфиг-файл роутера Плазы client_router.ini. Я пока не разобрался, нужно ли будет настраивать другие конфиги.

Это хорошо. Только зря вы убрали метод FindSection. Вообще лучше по максимуму переменные делать private и доступ к ним или через методы или через свойства. Лучше через методы, чтобы базовый класс делал базовую работу, а не просто отдавал свое состояние дочерним.

Еще список того, что может пригодиться:

1. Code

   var myNumber = Convert.ToInt32(myString);
   
   можно писать короче:
   
   Code

   var myNumber = myString.To<int>();
   
   
2. Code

   if (string.IsNullOrEmpty(arg))
   
   можно писать короче:
   
   Code

   if (arg.IsEmpty())
   
   

можно писать короче:

Проверка на null - это правильно. Но на следующей строчке MyEvent может стать null (в другом потоке произошла отписка от события) и будет NullReferenceException. Решается через доп переменную:



Если не создавать собственных делегатов (видимо равнение идет на Плазу, где они создаются автоматически, а не потому что так правильно), то запись будет короче:

int и Int32 - это алиасы. так же для bool и Boolean и т.д. Выражение вида:

эквивалентно:

Подниму топик парочкой советов:

1. internal на методы, свойста и поля (но не типа) в C# признак плохого дизайна. Говорит о том, что приосходит размытость границ логики.
   
2. Code

   Trace.WriteLineIf(TracingLevel > 2, record.GetStrings().Join(";"));
   Плох тем, что не важно, есть необходимый уровень трассировки или нет, строчка будет собираться всегда. Если такая конструкция встречается в коде, который вызывается часто, может снизить производительность.
   
3. Любите readonly. Тоесть, когда создаете поля, сразу их делайте readonly. Снять атрибут можно всегда. Но он предотвратит от нежелательной логики перетирания значения.
   
4. Два кода абсолютно эквивалентны:
   
   Code

   public class RootClass
   {
   private class NestedClass
   {
   internal int Prop { get; set; }
   }
   }
   
   
   
   Code

   public class RootClass
   {
   private class NestedClass
   {
   public int Prop { get; set; }
   }
   }
   
   

Сделал криво, знаю. Уже думал над тем, чтобы переделать + поменять internal на public. В релиз не будет попадать вообще: выделю в отдельный метод с аттрибутом [Conditional("DEBUG")]

Добрый день. Если верить http://www.codeproject.com/KB/cs/WeakEvents.aspx, кот. ссылается на Ecma cпецификацию, то для обеспечения потокобезопасности делегатов необходимо еще и локирование:

@esper, может выставишь у себя tab'ы (Tools \ Options \ Text Editor \ Tab \ Keep tabs)?

Сделал