To var or not to var

Использовать в коде var или нет? Я много спорил на эту тему с разными людьми и постепенно у меня сложилось мнение, что большинство путает var (C#) с var (Delphi). Отсюда и начинаются всякие упреки а-ля “вар ухудшает читаемость кода”, “вар повышает вероятность ошибок” и т.п. В случае с дельфовым var все понятно – это скорее зло, чем добро. Но в C# все обстоит немного по-другому, поскольку var – это просто syntactic sugar языка, не более чем, хотя и была введена для LINQ. Если браться за аналогии, то var от Delphi – это нечто похожее на dynamic C#, а вот уже dynamic да, нужно использовать с осторожностью.
Я для себя вывел правила, когда можно использовать var и когда за это лучше по рукам давать:

  1. Если из объявления переменной видно, какой у нее тип – используем var;
  2. В foreach используем явное указание типа.

И все. Проиллюстрирую:

var students = new List<Student>();
foreach (Student student in students)
{...}
int i = students.Count;
ReadOnlyCollection<Students> studentsCopy = students.AsReadOnly();

Строчка 1: видно, что List. Незачем дублировать в начале.

Строчка 4: сразу непонятно, какой тип у students.Count, потому нужно указать тип явно. Как и в случае строки 5.

И не забывайте, что если навести курсором на имя переменной, VS покажет попап с явным указанием типа, где, например, будет сказано, что students – это List, а не неизвестный до рантайма тип.

The Rules of Work

Начал читать книгу “The Rules of Work” by Richard Templar. Предварительно просмотрел о ней информацию в интернете. Отзывы разные, от хороших до плохих – как обычно. В народе книга прозвана “библией карьериста”. Что ж, можно согласиться. Есть некоторые разделы, которые “карьерны” просто до невозможности. Но в целом, закрывая глаза на эти мелкие недостатки, книга хороша. Очень стимулирует работать, дает какие-то мотивы и заставляет задуматься. Впрочем, задумываться заставляет каждая более-менее достойная книга. Но эффект от правил работы заметен – ощущаю в себе больше желания работать, причем работать так, чтобы можно было, придя вечером домой, устало вздохнуть и подумать “я столько сегодня сделал, круто”.

Конфликты команды разработчиков

В команде должны быть все люди с противоположными взглядами, и они должны отстаивать свое мнение, конфликт должен быть, именно благодаря ему проект не уйдет ни в одну из крайностей, а будет держатся оптимальной середины, вырастет вовремя хорошим и качественным, а не уродцем, которого тут же хочется забыть.

http://artamonov.ru/2009/11/30/conflicti-komandi-razrabotchikov/