Наконец, Сократовский метод заработал. А то тут все "умные" — желание учиться только
в декларациях, а чуть непонятная мысль — никто же не уточнит, сразу минус поставят,
и успокоятся.
Тогда следующий вопрос — а в качестве профи Вы чем собираетесь заниматься?
Первым делом подумал, что автору не больше 25-ти лет. Проверил — 22.
По стилю похоже. Общий призыв: учитесь вместо того, чтобы работать. Для такого возраста вполне здравый. Но хочу заметить, что советы подходят не всем. :)
Я по неткрафту с 2004-го года отслеживаю ситуацию. Сейчас на IIS 35% сайтов, на
Apache 50%. Последние 9 месяцев цифры стабильны. Похоже, разработчикам понравился ASP.NET.
Тогда я просто не понимаю назначение документа. Не могли бы Вы более точно его описать?
Например, почему правило про Exception подходит, а правило про Collection — нет.
Ну и в продолжение темы, отдельным постом для отдельного обсуждения — что ещё можно добавить.
1. Избегать избыточности в именах. Пример: пишем обёртку над ActiveDirectory, пространство имён называем ActiveDirectory. Классы внутри должны назвать User, Group, Computer, а не ADUser, ADGroup, ADComputer.
Второй пример:
class File
{
enum Mode { Read, Write };
}
File.Mode.Read, а не File.FileMode.Read и уж тем более не File.FileMode.ModeRead.
Третий пример, названия методов: File.Open, но не File.OpenFile.
2. Именование множественных объектов. Если есть объект класса T, то коллекцию называем TCollection, список TList. То есть StringCollection, StringList, но не StringsCollection, StringsList. Точно так же предлагаю стыковать имя класса с суффиксом Count: FieldCount, StringCount, FileCount.
Во множественном числе можно называть имена переменных, например FieldCollections fields.
3. Логические переменные, свойства и пр., имеют прифексы is, has: IsDeleted, но не Deleted, HasMoreElements, но не ContainsMoreElements.
4. Правила переноса длинных строк.
4.1. В случае сложных выражений необходимо выделить логическую структуру выражения, вынести отдельные блоки в самостоятельные операторы присваивания.
Вставлю свои 2 копейки. Возражения у меня появились, попробую их внятно изложить.
> Pascal casing для констант.
Я для себя решаю так: если константа публична, имя начинается с большой буквы. Если нет, то с маленькой. Если вдруг она перестанет быть константой и превратится в переменную, программу не придётся переписывать (хотя при наличии Refactoring rename это уже не так актуально, как раньше).
> При именовании переменных избегайте использования сокращенных вариантов вроде I и t,
> используйте index и temp. Не используйте венгерскую нотацию или используйте ее только для
> закрытых членов. Не сокращайте слова, используйте number, а не num.
Спорно. По крайей мере, существуют устоявшиеся конструкции, которые одинакого воспринимаются всеми без исключения программистами. Одна из них for(int i = 0; i < limit; i++).
Схватывается целиком. Ну и в целом, есть определённое количество случаев, когда короткие имена понимаются на лету. Постараюсь перечислить:
1. Математические функции. Например sin(T x) или atan2(T y, T x).
2. Целые переменные во вложенных циклах for: i, j, k...
3. Функции с говорящими именами, параметры которых не несут самостоятельного смысла: swap(T a, T b)
Кроме того, в коротких методах с простой структурой, я предпочитаю называть локальные переменные по большим буквам их типа. Например, FileInfo fi, DataReader dr. Ну, и отсюда с необходимостью следуют string s, File f, но только в том случае, если назначение этих переменных очевидно из названия метода.
По поводу num и number согласен.
> используйте промежуточную переменную для передачи bool-значения результата функции в
> условное выражение if;
Такой код для меня однозначно "с запашком" (по Фаулеру). Я обязательно при чтении остановлюсь и начнут думать: зачем сделали именно так? Думаю, эту рекомендацию надо убрать.
> избегайте методов с более чем 200 строками кода;
На мой взгляд, 20 является прекрасной верхней границей. :) Если встречаю большую функцию, рука сама тянется к Refactoring, Extract method. Ключ к читабельности программы вижу в том, что любой метод помещается на экране монитора полностью, тогда все остальные огрехи не так страшны.
> 3.1 Закрытые поля
Сам лично избегаю префиксов и в этом случае тоже. Если внешнее свойство называется Length, закрытая переменная будет называться length. Тут, сам понимаю — момент очень спорный. Тем не менее, считаю, что любые префиксы зло.
Если Вы используете map, reduce и прочее, почему
Вы называете свой код императивным? Этих средств
в императивных языках никогда не было.
И откуда такая асимметричность в подходе? Похоже,
независимо от того, какой будет код, Вы всё равно
будете считать его импративным с функциональными
вставками?
Кстати, правильно ли я Вас понял, что вы
противопоставляете ООП и ФП?
Слово "мультипарадигменный" Вам знакомо? И, давайте,
прежде, чем ссылаться на википедию, Вы ознакомитесь
с предметом?
В той же мере, Вы не можете назвать Python императивным.
Иначе мне придётся дать Вам ссылку на такие его возможности,
как map, reduce или та же lambda.
Ну а то, что лично Вами они не востребованы, показыват
только уровень Ваших представлений. Разработчики Python и Ruby,
думаю, с Вами не согласятся.
А контекст? Речь шла о том, как именно он будет выделен визуально
(или голосом). Автор может выбрать: подчеркнуть, сделать больше,
сделать толще, выбрать другой цвет.
Ну, я даже не знаю. MySQL и Apache на чистом Си писаны. Язык живой? Живой.
Но вот из новых программистов его мало кто изучает, и программисты на Си
нужны гораздо реже, чем программисты на Си++. А те, в свою очередь, на
Java. Это не гибель, это стагнация.
Грешно Вам обзываться. Тем более, что мысли моей Вы не поняли. Ну, для программистов это
явление известное, и даже закономерное.
Попробую сказать по другому. Десятилетием Си++ были годы 1991-2000. Появились
доступные компиляторы, вышло много книг, народ массово стал переходить, работодатели
заинтересовались. Тогда и было время для разработки стандартов. А сейчас время Си++ ушло, и смысла в новом стандарте не так много, как, скажем, в начале 2000-х. Сейчас время Java (ну и более узкого C#). Активно идёт работа над языками, появляются новые возможности,
выходит литература, множество предложений от работодателей (больше, чем по Си++, и уж
тем более, чем по Коболу и Фортрану, кстати, а Вы на Коболе сами пишите?)
А следующее десятилетие будет посвящено функциональным языкам.
По поводу идеализма я всю свою жизнь сентенции слышу. Мне в 92-93 годах тоже говорили,
что зря я изучаю Си++, язык то не востребован. Однако, к 97-му году ситуация изменилась
кардинально. И тем, кто говорил про идеализм, пришлось догонять. И с Java было то же самое.
Ужас какой. Разве я пророчил гибель? Я писал о бессмысленности нового стандарта
для Си++. А жить он будет очень долго, учитывая количество написанного кода.
в декларациях, а чуть непонятная мысль — никто же не уточнит, сразу минус поставят,
и успокоятся.
Тогда следующий вопрос — а в качестве профи Вы чем собираетесь заниматься?
По стилю похоже. Общий призыв: учитесь вместо того, чтобы работать. Для такого возраста вполне здравый. Но хочу заметить, что советы подходят не всем. :)
Apache 50%. Последние 9 месяцев цифры стабильны. Похоже, разработчикам понравился ASP.NET.
Например, почему правило про Exception подходит, а правило про Collection — нет.
1. Избегать избыточности в именах. Пример: пишем обёртку над ActiveDirectory, пространство имён называем ActiveDirectory. Классы внутри должны назвать User, Group, Computer, а не ADUser, ADGroup, ADComputer.
Второй пример:
File.Mode.Read, а не File.FileMode.Read и уж тем более не File.FileMode.ModeRead.
Третий пример, названия методов: File.Open, но не File.OpenFile.
2. Именование множественных объектов. Если есть объект класса T, то коллекцию называем TCollection, список TList. То есть StringCollection, StringList, но не StringsCollection, StringsList. Точно так же предлагаю стыковать имя класса с суффиксом Count: FieldCount, StringCount, FileCount.
Во множественном числе можно называть имена переменных, например FieldCollections fields.
3. Логические переменные, свойства и пр., имеют прифексы is, has: IsDeleted, но не Deleted, HasMoreElements, но не ContainsMoreElements.
4. Правила переноса длинных строк.
4.1. В случае сложных выражений необходимо выделить логическую структуру выражения, вынести отдельные блоки в самостоятельные операторы присваивания.
double velocity = sqrt(sqr(x1 - x2) + sql(y1 - y2))/time;
Должно быть:
double distance = sqrt(sqr(x1 - x2) + sql(y1 - y2));
double velocity = distance/time;
Методы с большим числом параметров, которые не помещаются на одну строку, оформляются так:
> Pascal casing для констант.
Я для себя решаю так: если константа публична, имя начинается с большой буквы. Если нет, то с маленькой. Если вдруг она перестанет быть константой и превратится в переменную, программу не придётся переписывать (хотя при наличии Refactoring rename это уже не так актуально, как раньше).
> При именовании переменных избегайте использования сокращенных вариантов вроде I и t,
> используйте index и temp. Не используйте венгерскую нотацию или используйте ее только для
> закрытых членов. Не сокращайте слова, используйте number, а не num.
Спорно. По крайей мере, существуют устоявшиеся конструкции, которые одинакого воспринимаются всеми без исключения программистами. Одна из них for(int i = 0; i < limit; i++).
Схватывается целиком. Ну и в целом, есть определённое количество случаев, когда короткие имена понимаются на лету. Постараюсь перечислить:
1. Математические функции. Например sin(T x) или atan2(T y, T x).
2. Целые переменные во вложенных циклах for: i, j, k...
3. Функции с говорящими именами, параметры которых не несут самостоятельного смысла: swap(T a, T b)
Кроме того, в коротких методах с простой структурой, я предпочитаю называть локальные переменные по большим буквам их типа. Например, FileInfo fi, DataReader dr. Ну, и отсюда с необходимостью следуют string s, File f, но только в том случае, если назначение этих переменных очевидно из названия метода.
По поводу num и number согласен.
> используйте промежуточную переменную для передачи bool-значения результата функции в
> условное выражение if;
Такой код для меня однозначно "с запашком" (по Фаулеру). Я обязательно при чтении остановлюсь и начнут думать: зачем сделали именно так? Думаю, эту рекомендацию надо убрать.
> избегайте методов с более чем 200 строками кода;
На мой взгляд, 20 является прекрасной верхней границей. :) Если встречаю большую функцию, рука сама тянется к Refactoring, Extract method. Ключ к читабельности программы вижу в том, что любой метод помещается на экране монитора полностью, тогда все остальные огрехи не так страшны.
> 3.1 Закрытые поля
Сам лично избегаю префиксов и в этом случае тоже. Если внешнее свойство называется Length, закрытая переменная будет называться length. Тут, сам понимаю — момент очень спорный. Тем не менее, считаю, что любые префиксы зло.
Вы называете свой код императивным? Этих средств
в императивных языках никогда не было.
И откуда такая асимметричность в подходе? Похоже,
независимо от того, какой будет код, Вы всё равно
будете считать его импративным с функциональными
вставками?
Кстати, правильно ли я Вас понял, что вы
противопоставляете ООП и ФП?
прежде, чем ссылаться на википедию, Вы ознакомитесь
с предметом?
В той же мере, Вы не можете назвать Python императивным.
Иначе мне придётся дать Вам ссылку на такие его возможности,
как map, reduce или та же lambda.
Ну а то, что лично Вами они не востребованы, показыват
только уровень Ваших представлений. Разработчики Python и Ruby,
думаю, с Вами не согласятся.
"выделить" слишком много значений. :)
подобное. :)
функциональная парадигма прекрасно поддерживается.
(или голосом). Автор может выбрать: подчеркнуть, сделать больше,
сделать толще, выбрать другой цвет.
Но вот из новых программистов его мало кто изучает, и программисты на Си
нужны гораздо реже, чем программисты на Си++. А те, в свою очередь, на
Java. Это не гибель, это стагнация.
явление известное, и даже закономерное.
Попробую сказать по другому. Десятилетием Си++ были годы 1991-2000. Появились
доступные компиляторы, вышло много книг, народ массово стал переходить, работодатели
заинтересовались. Тогда и было время для разработки стандартов. А сейчас время Си++ ушло, и смысла в новом стандарте не так много, как, скажем, в начале 2000-х. Сейчас время Java (ну и более узкого C#). Активно идёт работа над языками, появляются новые возможности,
выходит литература, множество предложений от работодателей (больше, чем по Си++, и уж
тем более, чем по Коболу и Фортрану, кстати, а Вы на Коболе сами пишите?)
А следующее десятилетие будет посвящено функциональным языкам.
По поводу идеализма я всю свою жизнь сентенции слышу. Мне в 92-93 годах тоже говорили,
что зря я изучаю Си++, язык то не востребован. Однако, к 97-му году ситуация изменилась
кардинально. И тем, кто говорил про идеализм, пришлось догонять. И с Java было то же самое.
для Си++. А жить он будет очень долго, учитывая количество написанного кода.
выражения. Вы о каких языках говорите?