Аннотация:
Этот документ описывает единый стиль кода, разработанный командой RSDN. В первую очередь он предназначен для использования в проектах, ведущихся в рамках RSDN. Надеемся, что этот стиль будет полезен всем тем, кто так же ищет удобный единый стиль форматирования исходного кода.
А> Не используйте подчеркивание для отделения слов внутри идентификаторов, это удлиняет идентификаторы и затрудняет чтение.
1). Сравните: "VeryLongNameOfSomeVariable" и "very_long_name_of_some_variable". IMHO второе намного читабельнее. Всё-таки в русском языке мы разделяем слова пробелами, а не изменением регистра букв.
2). Сравните: "TcpUdpIcmpAndIpClassName" и "TCP_UDP_ICMP_and_IP_class_name". Во втором случае аббревиатуры остались в привычном для глаза виде и при чтении лучше распознаются.
А>1). Сравните: "VeryLongNameOfSomeVariable" и "very_long_name_of_some_variable". IMHO второе намного читабельнее. Всё-таки в русском языке мы разделяем слова пробелами, а не изменением регистра букв.
Ты видать на php долгое время писал, вот тебе и читабельнее Да и памяти вторая строка больше займет
А>2). Сравните: "TcpUdpIcmpAndIpClassName" и "TCP_UDP_ICMP_and_IP_class_name". Во втором случае аббревиатуры остались в привычном для глаза виде и при чтении лучше распознаются.
Ну во первых названия совсем уж бредовые как для именования. А во вторых, это Соглашение в основном предназначено для написания под .NET, а там разделение кода с помощью подчеркивания довольно дико смотрится рядом с тем же кодом фреймворка.
Здравствуйте, Andre, Вы писали:
А>>1). Сравните: "VeryLongNameOfSomeVariable" и "very_long_name_of_some_variable". IMHO второе намного читабельнее. Всё-таки в русском языке мы разделяем слова пробелами, а не изменением регистра букв.
A>Ты видать на php долгое время писал, вот тебе и читабельнее
Нет. Всё как-то больше на C и для ядра линукса.
Ты хотя бы попытайся оторваться от своих привычек и посмотреть на то, как выглядят эти две переменные _непредвзято_.
A>Да и памяти вторая строка больше займет
На целых 5 байт. Если это будет читабельнее, то цена оправдана.
А>>2). Сравните: "TcpUdpIcmpAndIpClassName" и "TCP_UDP_ICMP_and_IP_class_name". Во втором случае аббревиатуры остались в привычном для глаза виде и при чтении лучше распознаются.
A>Ну во первых названия совсем уж бредовые как для именования.
Может предложишь что-нибудь взамен? Мне подобные названия регулярно попадаются.
A>А во вторых, это Соглашение в основном предназначено для написания под .NET, а там разделение кода с помощью подчеркивания довольно дико смотрится рядом с тем же кодом фреймворка.
Вот и не надо подводить под это какие-то странные обоснования типа "читабельнее".
Надо было прямо написать "MS за нас всё придумала. Ни шага в сторону.".
Здравствуйте, <Аноним>, Вы писали:
А>Нет. Всё как-то больше на C и для ядра линукса.
То-то я смотрю в ядре Линукса чет ногу сломит. Значит это были происки наших аноноимов.
А>Ты хотя бы попытайся оторваться от своих привычек и посмотреть на то, как выглядят эти две переменные _непредвзято_.
Шутку понял, смешно. (с)
А>Может предложишь что-нибудь взамен? Мне подобные названия регулярно попадаются.
Вот ты и привык жтому бреду. Номальные названия выглядят как-то так:
TcpServerChannel
UdpClient
...
А>Вот и не надо подводить под это какие-то странные обоснования типа "читабельнее". А>Надо было прямо написать "MS за нас всё придумала. Ни шага в сторону.".
И что характено, Sun с IBM-ом тоже на за нас все решили. Так что придется тебе или привыкать, или писать исключительно для Линукс-кернела, чтобы простой народ не пугать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, <Аноним>, Вы писали:
VD>То-то я смотрю в ядре Линукса чет ногу сломит. Значит это были происки наших аноноимов.
Без перехода на личности никак?
А>>Ты хотя бы попытайся оторваться от своих привычек и посмотреть на то, как выглядят эти две переменные _непредвзято_.
VD>Шутку понял, смешно. (с)
Здравствуйте, Аноним, Вы писали:
А>> Не используйте подчеркивание для отделения слов внутри идентификаторов, это удлиняет идентификаторы и затрудняет чтение.
А>1). Сравните: "VeryLongNameOfSomeVariable" и "very_long_name_of_some_variable". IMHO второе намного читабельнее. Всё-таки в русском языке мы разделяем слова пробелами, а не изменением регистра букв. А>2). Сравните: "TcpUdpIcmpAndIpClassName" и "TCP_UDP_ICMP_and_IP_class_name". Во втором случае аббревиатуры остались в привычном для глаза виде и при чтении лучше распознаются.
Такие длинные (многосоставные) названия... это мне кажеться в дизайне что-то не додумано. Или язык какой-нить процедурный. А так вроде бы и мотива нет. Что-то похоже на "Меня зовут КлиновыйЛистУпавшийНаЗакатеВСерединеОсени", что-то индейское чес слово.
А>Авторы: А>RSDN Team
А>Аннотация: А>Этот документ описывает единый стиль кода, разработанный командой RSDN. В первую очередь он предназначен для использования в проектах, ведущихся в рамках RSDN. Надеемся, что этот стиль будет полезен всем тем, кто так же ищет удобный единый стиль форматирования исходного кода.
меня почему-то коребит от того что такие вещи как if и for и т.п. вещи в основном народе пытаеться зщаписывать в таком виде:
if ( some expression )
for ( .... )
foreach ( )
и знаете что корёбит? пробел между скобкой и ключивым словом!
подумайте ведь записать if без скобки не возможно — ошибка компилятора! записать for без скобки — ошибка компилятора... и т.д. так какого разделять ключевое слово и скобку? они не могут жить отдельно!
и не надо говорить что так мол удобней печатать, это все дело привычки, а вот логическую компоновку это нарушает.
пример хорошого для меня кода:
if( const == something )
{
for( int i=0; i < 10; i++ )
{
/// и т.д.
}
}
ключевые слова не отделяються от скобок пробелами...
Здравствуйте, alku, Вы писали:
A>пример хорошого для меня кода:
И не хорошего для меня...
A>
A>if( const == something )
A>
A>ключевые слова не отделяються от скобок пробелами... A>жду коментов...
В данном случае по моему мнению страдает читабельность. Я привык ключевым словом читать if, а не if(, поэтому когда я читаю код, глаз выхватывает ключевые слова и мозг строит из них структуру. Скобки в данном случае лишь сущность группировки, выделение условия как единого целого.
Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, alku, Вы писали:
A>>пример хорошого для меня кода: O>И не хорошего для меня...
A>>
A>>if( const == something )
A>>
A>>ключевые слова не отделяються от скобок пробелами... A>>жду коментов... O>В данном случае по моему мнению страдает читабельность. Я привык ключевым словом читать if, а не if(, поэтому когда я читаю код, глаз выхватывает ключевые слова и мозг строит из них структуру. Скобки в данном случае лишь сущность группировки, выделение условия как единого целого.
но не отделимая часть... ты при взгляде должен выхватывать не только ключевое слово, но и правильность конструкции языка.
O>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
тут хочу поспорить... зачем равнять искуственный язык програмирования с языком разговорным/письменным?! у них разные цели...
для програмистского языка важные такие вещи, как:
— компактность записи
— удобство навигации по коду
— читабельность
для литературного языка такого нет! почему?! да потому что литературный язык изначально расчитывался на книги без удобств с поиском и навигацией банальное юзабилити компутера — для книг такого нет!
для примера:
— если поставить скобку сразу за ключивым словом, то нажатием Ctrl+] мы получим сразу переход на закрывающюю скобку
— если не ставить, то у нас на одно действие больше! сдвиг на один символ вправо... Arrow Right or Ctrl+ArrowRight
для выделения ключевых слов в коде служит расскраска, а не пробелы! и тут все зависит от того как человек настроил расскраску и на сколько в расскраске выделяються нужные вещи, такие как ключевые слова. человек должен при взгляде на экран сразу выхватывать ключевые слова.
А>Авторы: А>RSDN Team
А>Аннотация: А>Этот документ описывает единый стиль кода, разработанный командой RSDN. В первую очередь он предназначен для использования в проектах, ведущихся в рамках RSDN. Надеемся, что этот стиль будет полезен всем тем, кто так же ищет удобный единый стиль форматирования исходного кода.
еще одна фича:
кто смотрел код от макрософта рефлектором должен был заметить как именуються мемберы классов!!! они все начинаються с m_... странно это очень... в своем стиле они пишут что так не надо делать и тутже смотрим на код и видим что все там не так...
может просто существует два старндарта? один для юзеров другой для внутренних рабочих?
сам я ксатити по с++ привычке до сих пор все мемберы класса с m_ начинаю... может это все не так плохо как может показаться... венгерскую натаю народ и так сильно не юзал и использовал ее укороченный вариант:
— для строк m_str*
— для bool m_b*
иногда для int и long... а все остальное очень походе на то что щас предлагает делать Макрософт...
объяснюсь почему меня эта тема очень волнует:
— щас на фирме я пытаюсь написать стандарт на оформление кода для c# проектов...
в основном это надо для студентов, но и "старым" программерам тоже иногда полезно...
а то очень часто возникает ситуация, что два програмера не могут сойтись во мнении сколько должна занимать табуляция, надо ли вообще использовать табуляции... как надо записывать операторы, декларации и т.д. и т.п.
я пытаюсь написать документ который просто и банально решит такой вопрос — аля корпоративный стандард на оформление кода. в него кстатит должны войти правила по оформлению и безопасности кода... как только напишеться документ обязательно постараюсь поделиться с общественностью.
Здравствуйте, alku, Вы писали:
A>>>ключевые слова не отделяються от скобок пробелами... O>>В данном случае по моему мнению страдает читабельность. Я привык ключевым словом читать if, а не if(, поэтому когда я читаю код, глаз выхватывает ключевые слова и мозг строит из них структуру. Скобки в данном случае лишь сущность группировки, выделение условия как единого целого.
A>но не отделимая часть... ты при взгляде должен выхватывать не только ключевое слово, но и правильность конструкции языка.
Правильность конструкции нужна только при написании кода, но читается код на порядки чаще, чем пишется.
O>>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
A>тут хочу поспорить... зачем равнять искуственный язык програмирования с языком разговорным/письменным?! у них разные цели...
Подискутируем Только сразу хочу предупредить, всё это — дело привычки. Это как о тапочках спорить... И весь смысл данных "Соглашений" исключительно для работы в команде, чтобы код был оформлен единообразно.
A>для програмистского языка важные такие вещи, как: A>- компактность записи
Зачем? Купи монитор побольше Шутка, конечно, но в каждой шутке... Я не вижу смысла в компактности записи, это же не Obfuscated C++.
A>- удобство навигации по коду
Верно, но при чём здесь скобки? См. также дальше.
A>- читабельность
Вот это — самое главное, на мой взгляд. И тщательно отделенные лексемы — залог быстрого и легкого чтения.
A>для примера: A>- если поставить скобку сразу за ключивым словом, то нажатием Ctrl+] мы получим сразу переход на закрывающюю скобку A>- если не ставить, то у нас на одно действие больше! сдвиг на один символ вправо... Arrow Right or Ctrl+ArrowRight
Спорно. Во-первых, зачем переходить на закрывающую скобку? Так что-ли не видно, где она? Я еще понимаю, на фигурную скобку, закрывающую блок или метод, но это уже на мой взгляд слишком большой метод, если на экране не помещается, кандидат на разделение.
A>для выделения ключевых слов в коде служит расскраска, а не пробелы! и тут все зависит от того как человек настроил расскраску и на сколько в расскраске выделяються нужные вещи, такие как ключевые слова. человек должен при взгляде на экран сразу выхватывать ключевые слова.
Ну конечно можно из кода сделать помесь радуги и павлиньего хвоста, но надо ли? Если структура даёт гораздо больше информации? ИМХО.
Здравствуйте, alku, Вы писали:
A>еще одна фича:
Ну, поскольку нас тут сегодня не много, я снова влезу
A>кто смотрел код от макрософта рефлектором должен был заметить как именуються мемберы классов!!! они все начинаються с m_... странно это очень... в своем стиле они пишут что так не надо делать и тутже смотрим на код и видим что все там не так...
На самом деле, в FCL смешаны как минимум 4 подхода к именованию членов класса:
_member
m_member
member
_Member
Может и другие есть. Так что это косяк MS и никакой глубокой идеи в этом нет.
A>может просто существует два старндарта? один для юзеров другой для внутренних рабочих?
Существует неряшливость конкретных разработчиков, пишуших код несоответствующий принятому в компании стандарту.
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, alku, Вы писали:
A>>еще одна фича: O>Ну, поскольку нас тут сегодня не много, я снова влезу
A>>кто смотрел код от макрософта рефлектором должен был заметить как именуються мемберы классов!!! они все начинаються с m_... странно это очень... в своем стиле они пишут что так не надо делать и тутже смотрим на код и видим что все там не так... O>На самом деле, в FCL смешаны как минимум 4 подхода к именованию членов класса: O>_member O>m_member O>member O>_Member
O>Может и другие есть. Так что это косяк MS и никакой глубокой идеи в этом нет.
A>>может просто существует два старндарта? один для юзеров другой для внутренних рабочих? O>Существует неряшливость конкретных разработчиков, пишуших код несоответствующий принятому в компании стандарту.
что-то очень сомнительно... у макрософта все достаточно сторого и произвола девелопера они скорее всего не допустят... код у них проходит слишком много стадий, чтобы такую неряшлевость не заметили...
тестирование, код ревью и т.д. и т.п. вещи... так что думаю что стандартов все-таки много или они существуют для каждой группы разработчиков свои.
хочу заметить одну нашу неточность — стандарта на форматирование нету, есть только рекомендации!!! по-этому лучше дальше в диалоге использвать слово рекомендации, а не стандард.
Здравствуйте, alku, Вы писали:
A>>>может просто существует два старндарта? один для юзеров другой для внутренних рабочих? O>>Существует неряшливость конкретных разработчиков, пишуших код несоответствующий принятому в компании стандарту.
A>что-то очень сомнительно... у макрософта все достаточно сторого и произвола девелопера они скорее всего не допустят...
Факт есть факт Допускают. Например, код мог выйти из исследовательских лабораторий, или вообще адаптирован из кода сторонних компаний, приобретенных MS. Теоретически мог быть какой-нибудь outsourcing (хотя я таких случаев не знаю).
A>код у них проходит слишком много стадий, чтобы такую неряшлевость не заметили...
Могли заметить, и даже наказать. Но не исправить, ибо это а) дорого б) потенциально опасно в) имеет низкий приоритет.
A>так что думаю что стандартов все-таки много или они существуют для каждой группы разработчиков свои.
Ну давай мы проще поступим, я спрошу у MS
A>хочу заметить одну нашу неточность — стандарта на форматирование нету, есть только рекомендации!!! по-этому лучше дальше в диалоге использвать слово рекомендации, а не стандард.
На RSDN есть рекомендации, соглашения и всё что угодно, но не стандарты. В серьезной компании есть стандарты, но никак не рекомендации. Миллионы и гигабайты строк кода, написаных в разном стиле невозможно сопровождать. Люди не вечны, тем более их работа на одном месте. На смену одним приходят другие, которые должны легко читать чужой код.
Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG?
разумееться один метод форматирования не может претендовать на панацею от всех бед... среда разработки объединяет в себе много вещей которые облегчают чтение кода. это раскраска, форматирование, навигация && outlinning и т.д.
зачем прыгать по открытой закрытой скобке? ну иногда все-таки в if записыветься больше чем одно условие... про рефакторинг можно не расказыать — это возможный кандидат на вынесеине в переменную и т.п. но иногда случаеться.
для примера:
procteted void TestMethod( string data, string format )
{
/// check input parametersif( data == null || data.Length == 0 )
throw new ArgumentNullException( "data" );
if( format == null || format.Length == 0 )
throw new ArgumentNullException( "format" );
/// другой код
}
но очень возможно что в if будет и больше условий... или они будут занимать намного больше места.
я не навязываю свое мнение, я просто прошу вас помочь оценить удобство разных стилей записи... читабельность не теряеться, но это уже возможно дело привычки...
а вот маленький пример где выделеные скобки все-таки полезны:
Да можно и не спрашивать, они уже ответили практически. Есть такая замечательная утилита FxCop, которая проверяет сборки на соответствие различным правилам, в том числе и стандарту кодирования. Так вот, народ начал активно интересоваться, почему же эта утилита активно ругается на собственные сборки Microsoft. И здесь можно почитать ответ, почему же в коде фреймворка встечаются различные анахронизмы вроде m_ и прочего
Кстати, ссылку не приведу, но на прошлой недел читал блог какого то перца из Microsoft, который говорил что в данный момент код у них ежедневно прогоняется FxCop для контроля, потом ложится отчет и разработчики могут использовать его для фонового рефакторинга.
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, alku, Вы писали:
A>>так что думаю что стандартов все-таки много или они существуют для каждой группы разработчиков свои. O>Ну давай мы проще поступим, я спрошу у MS
если есть возможность, то почему бы не спросить?!
A>>хочу заметить одну нашу неточность — стандарта на форматирование нету, есть только рекомендации!!! по-этому лучше дальше в диалоге использвать слово рекомендации, а не стандард. O>На RSDN есть рекомендации, соглашения и всё что угодно, но не стандарты. В серьезной компании есть стандарты, но никак не рекомендации. Миллионы и гигабайты строк кода, написаных в разном стиле невозможно сопровождать. Люди не вечны, тем более их работа на одном месте. На смену одним приходят другие, которые должны легко читать чужой код.
к чему и стремимся... главное команда, а не один человек...
O>Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG?
Offtopic конечно, но интересно... не думал на эту тему искать во всем скрытый смысл требует времени