Здравствуйте Undutchable, Вы писали:
А>>Какой стиль выбрать ? Мне кажется стиль 2 намного удобнее.
U>Я пользуюсь вторым, чтобы было проще отслеживать вложенные скобки.
И я тоже.
U>PS По стилю программирования, мне кажется, вопросы открываются в Прочем (или я не прав?)
А>Какой стиль выбрать ? Мне кажется стиль 2 намного удобнее.
Я тоже для себя (давно уже) выбрал 2-й стиль. Даже сдается мне, что древние программисты (типа Кернигана и Ритчи) предпочитали именно этот стиль. Но не все так просто. Не так давно мне пришлось общаться с одной американской фирмой по написанию одной (не слишком сложной) программы. Так вот, одним из из условий было соблюдение ИХ стиля оформления исходного текста. Вот некоторые пункты (что помню):
1) if, while и т.д. должны иметь стиль, как у тебя стиль 1
2) после if, while, switch и т.д. должен быть один пробел, а уже затем открывающая скобка
3) отступы должны состоять из 4-х пробелов
4) комментарии подобно их примеру (сейчас уже не вспомню)
5) имена переменных должны быть в венгерской нотации (был пример)
Здравствуйте econt, Вы писали:
E>Я тоже для себя (давно уже) выбрал 2-й стиль. Даже сдается мне, что древние программисты (типа Кернигана и Ритчи) предпочитали именно этот стиль.
<...>
Вероятно, маэстро изволит шутить? (1) обычно именуется не иначе как K&R style, где буковка K означает Kernighan А, вообще, по этому поводу есть статейка в Jargon File.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
А>>Какой стиль выбрать ? Мне кажется стиль 2 намного удобнее.
E>Я тоже для себя (давно уже) выбрал 2-й стиль. Даже сдается мне, что древние программисты (типа Кернигана и Ритчи) предпочитали именно этот стиль.
K&R стилем называется как раз первый.
Но не все так просто. Не так давно мне пришлось общаться с одной американской фирмой по написанию одной (не слишком сложной) программы. Так вот, одним из из условий было соблюдение ИХ стиля оформления исходного текста.
Где то я видел целую кучу автоматических расстановщиков стилей,
можно писать как хочешь а потом кодировать перед посылкой.
P.S. Я тоже предпочитаю второй, и вообще последнее время баланс
меняется в его сторону, притом прямопропорционально ширине
диагонали монитора. Одним из аргументов в ползу первого было
то что он не занимает лишнее место
if () {
}
это 2 строки
if ()
{
}
это 3.
С 25 строками на экране из которых под
редактор дано 15 это имело смысл,
а сейчас стало не сильно актуально.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
1. Случай для одного разработчика.
Пиши как угодно. Лишь бы тебе было понятно. Некоторые из моих знакомы писали на Паскале в одну строчку.
Я использую 2, он нагляднее.
В древние временя я писал на Паскале и после каждого end писал коммент: end; {for} или end; {repeat}
Мои программы легко понимали челы даже отдаленно знакомые с Паскалем.
Иногда приходится переносить куски кода из одного проекта в другой и тд. В случае с 1 много непоняток с отслеживанием скобок.
2. Случай для группы разработчиков.
Использовать надо то, что выбрано всеми. Так понятнее. Многие конторы вводят обязательные правила для оформления программ.
MFC и MSCRT юзают 2.
3. Случай с STL. Там стиль Питоновский. Не очень наглядный, но есть свои преимущества. Ходят слухи, что это оттого, что STL рождалась Питоном. Вообще, при расширении библиотеки следует использовать тот стиль оформления, именования и тд., которого придерживались создатели библиотеки.
А>1. А>-------- А>
switch (a) {
case 1:
//break;
case 1:
//break;
default:
//
} //switch (a)
последний комментарий //switch — если switch вылазит за пределы экрана (применяю также и к остальным конструкциям)
case переносится на 4 символа для того, чтобы на одной вертикальной линейке были только открывающие и закрывающие конструкции (напр., switch и закрывающая скобка). То же правило и для остального, т.е. написав
if ()
{
}
на одной линии оказывается 3 элемента, а не 2.
Поэтому в предложенных 2-х вариантах всегда выбираю 2-й — меньше места, чем 1-й и одновременно понятен не меньше.
A>>там { } не нужны, просто не зачем DS>Во-первых красивее, во-вторых — это эе область видимости
А зачем там область видимости?
Или ты собираешься там еще кучу переменных в каждый case вводить с одинаковыми названиями?
Да даже если и так? Отработав один case прога по break перейдет за пределы switch и они так и так уже не будут видны... Или я что-то упустил?
Здравствуйте Anatolix, Вы писали:
E>>Я тоже для себя (давно уже) выбрал 2-й стиль. Даже сдается мне, что древние программисты (типа Кернигана и Ритчи) предпочитали именно этот стиль.
A>K&R стилем называется как раз первый.
Да, что-то я забывать стал основоположников... Книжку эту я последний раз читал лет так 8 назад. Так что за замечание спасибо.
Здравствуйте Undutchable, Вы писали:
U>Здравствуйте Аноним, Вы писали:
U>... А>>Какой стиль выбрать ? Мне кажется стиль 2 намного удобнее.
U>Я пользуюсь вторым, чтобы было проще отслеживать вложенные скобки.
Специально попробовал в своем текущем проете использовать оба эти стиля и сравнить их, надо отметить, что первый гораздо удобнее и наглядней, с использованием первого возникает эффект удлиннения блоков кода и хуже
охваьывается структура кода и логика, так что для логики полезней, на мой взгляд второй вариант, а для человеко/сторок конечно первый =)
Хотя это всего лишь мое мнение.
Взойти на гору можно разными путями, но само восхождение остается неизменным.
Здравствуйте Aquary, Вы писали:
A>Здравствуйте achp, Вы писали:
A>>>>>Или я что-то упустил? DS>>>>Yah (Да, то есть ) A>>>Что? A>>Ошибка компиляции: переход в обход инициализации объекта.
A>Ты про что? откомпилил (изменив case 1 на case 2 ), заработало...
switch (variant)
{
case 1:
my_brilliant_class_that_desperately_needs_initialization x;
// ...break;
case 2:
// ...
}
Несмотря на break объект x видим после метки case 2. Т. е. к нему можно обращаться, он там "живет". Но! В случае перехода к этой метке инициализация x остается обойденной, что компилятором и не допускается.
Здравствуйте achp, Вы писали:
A>>Ты про что? откомпилил (изменив case 1 на case 2 ), заработало...
A>
A>switch (variant)
A>{
A>case 1:
A> my_brilliant_class_that_desperately_needs_initialization x;
A> // ...
A> break;
A>case 2:
A> // ...
A>}
A>
A>Несмотря на break объект x видим после метки case 2. Т. е. к нему можно обращаться, он там "живет". Но! В случае перехода к этой метке инициализация x остается обойденной, что компилятором и не допускается.
Это все правильно, только вот скажи — часто ли тебе приходится объявлять объекты класса внутри case? ИМХО, несколько некрасиво это... ИМХО...
A>>Несмотря на break объект x видим после метки case 2. Т. е. к нему можно обращаться, он там "живет". Но! В случае перехода к этой метке инициализация x остается обойденной, что компилятором и не допускается.
A>Это все правильно, только вот скажи — часто ли тебе приходится объявлять объекты класса внутри case? ИМХО, несколько некрасиво это... ИМХО...
[skipped]
A>Это все правильно, только вот скажи — часто ли тебе приходится объявлять объекты класса внутри case? ИМХО, несколько некрасиво это... ИМХО...
Здравствуйте Aquary, Вы писали:
F>>>А с кейсами как быть?
A>
DS>> case 1:
DS>> {
DS>> ...
DS>> break;
DS>> }
A>
A>там { } не нужны, просто не зачем
A>я пишу A>
A>switch (a) {
A> case 1:
A> //
A> break;
A> case 1:
A> //
A> break;
A> default:
A> //
A>} //switch (a)
A>
Если внутри ветки case есть переменная с нетривиальной инициализацией (класс с конструктором, переменная 'int' объявленная с инициализатором и т.п.) то без фигурных скобок ты получишь сообщение об ошибке компиляции.
A>>Несмотря на break объект x видим после метки case 2. Т. е. к нему можно обращаться, он там "живет". Но! В случае перехода к этой метке инициализация x остается обойденной, что компилятором и не допускается.
A>Это все правильно, только вот скажи — часто ли тебе приходится объявлять объекты класса внутри case? ИМХО, несколько некрасиво это... ИМХО...
Во-первых, мне, например, часто.
Во-вторых, это не обязятельно должен быть экземпляр класса. С обычным 'int i = 0;' будет то же самое — сообщение об ошибке компиляции.
АТ>Если внутри ветки case есть переменная с нетривиальной инициализацией (класс с конструктором, переменная 'int' объявленная с инициализатором и т.п.) то без фигурных скобок ты получишь сообщение об ошибке компиляции.
Да это все понятно я изначально имел в виду, что их там может и не быть по стандарту не более того
Конечно, в приведенных случаях, там обязаны быть и скобки.
Изначально другое интересно было — кто как форматирует это дело.
Cо скобками в первом стиле это будет
Здравствуйте Aquary, Вы писали:
A>Изначально другое интересно было — кто как форматирует это дело. A>Cо скобками в первом стиле это будет
A>
A>case 1: {
A> do1();
A> break;
A>}
A>case 2{
A> do2();
A> break;
A>}
A>
Я бы не называл все это "стилем программирования". К стилю программирования это никакого оотношения не имеет. Это скорее деталь стиля оформления исходных файлов. Я на практичке встречаю три стиля оформления:
if (expression) {
statement;
}
if (expression)
{
statement;
}
if (expression)
{
statement;
}
Я пользуюсь средним вариантом. Давно не встречал последнего, хотя на одной из предыдущих работ им пользовались многие. В ветках 'case' я ставлю фигурные скобки только если они там действительно нужны (ветка содержит обпределения локальных объектов).
Мне представляется разумным следующий стиль оформления исходников:
1. Фигурные скобки
{
// Фигурные скобки одна под другой
// Открывающая фигурная скобка всегда одинока на своей строчке, даже без комментария
}
Заключенное между фигурными скобками тело пространства имен первого уровня, кроме безымянного, не сдвигается, а вместо этого отбивается пустыми строками:
namespace имя
{
t f();
namespace вложенное
{
t1 f1();
}
}
namespace
{
t2 f2();
}
2. Циклы while и условные операторы
Если тело цикла или часть "то" или "иначе" условного оператора является чем-то иным, нежели оператором-выражением, оно заключается в фигурные скобки, даже если синтаксис этого не требует:
while (что-то)
{ // Синтаксис не требует здесь фигурных скобокif (нечто)
оператор-выражение
}
3. else, while после фигурной скобки
Ключевые слова else, а также while, относящееся к циклу do-while, располагаются на одной строке с фигурной скобкой, завершающей предшествующее им тело цикла или часть "то" условного оператора, ежели таковая наличествует:
if (что-то)
{
// Много чего
} else// Не является "самостоятельным", поэтому вслед за скобкой
// Черт-те что!
А также:
do
{
// Много чего
} while (что-то) // Не является "самостоятельным", поэтому вслед за скобкой
Здравствуйте achp, Вы писали:
A>Мне представляется разумным следующий стиль оформления исходников:
[тут сожрали демоны] A>Интересно было бы услышать критические замечания.
1. места много уходит на одиночные скобки на строке — это уже писали
2. вложенные namespace лучше смещать на 4 символа, как и все остальное — нагляднее.
Вообще, имхо, любые вложения лучше смешать — чтобв открывающий и закрывающий элемент были на одногй "линии" — лучше отслеживать, где начало и где конец блока.
Здравствуйте Aquary, Вы писали:
A>Здравствуйте Dr_Sh0ck, Вы писали: F>>>А с кейсами как быть?
A>
DS>> case 1:
DS>> {
DS>> ...
DS>> break;
DS>> }
A>
A>там { } не нужны, просто не зачем
A>я пишу A>
A>switch (a) {
A> case 1:
A> //
A> break;
A> case 1:
A> //
A> break;
A> default:
A> //
A>} //switch (a)
A>
Только вот "пустой" default не получится: компилятор ругается...
A>последний комментарий //switch — если switch вылазит за пределы экрана (применяю также и к остальным конструкциям)
Здравствуйте Aquary, Вы писали:
A>Здравствуйте achp, Вы писали:
A>>Мне представляется разумным следующий стиль оформления исходников: A>[тут сожрали демоны] A>>Интересно было бы услышать критические замечания.
A>1. места много уходит на одиночные скобки на строке — это уже писали
Точно! У меня как раз места на диске не хватает: надо куда-то переписать 2 или 3 гигабайта видео, уже и болванки лежат, да все руки не доходят...
Здравствуйте The Lex, Вы писали:
TL>Только вот "пустой" default не получится: компилятор ругается...
Ну это я уже не стал дописывать — идею только демонстрировал
A>>последний комментарий //switch — если switch вылазит за пределы экрана (применяю также и к остальным конструкциям) TL>Поддерживаю...
Это из Голуба, что ли... не помню... Кто-нибудь еще этим пользуется?
Здравствуйте Aquary, Вы писали:
A>Здравствуйте The Lex, Вы писали:
TL>>Только вот "пустой" default не получится: компилятор ругается... A>Ну это я уже не стал дописывать — идею только демонстрировал
A>>>последний комментарий //switch — если switch вылазит за пределы экрана (применяю также и к остальным конструкциям) TL>>Поддерживаю... A>Это из Голуба, что ли... не помню... Кто-нибудь еще этим пользуется?
Не, Голуба я не знаю. Это из моих исходников. А еще есть глупая привычка в конце функции ее название приписывать:
someType SomeFunction()
{
// Some code
// ...
} // Some Function
Потому как совсем невмоготу стараться вникнуть в то, "где начало этого конца". И размеры экрана тут не при чем: у меня сейчас 1024 высоты имеется — все равно сильно много задумываться лень — проще задокументировать. Не все подряд, конечно, но каждый хвост, претендующий на сколь бы то ни было порядочную длинну, следует подписать. Мое скромное мнение, разумеется...
C>Я использую стиль 1, но возможно есть идеи и лучьше?
В целях последующих изменений (а это почти всегда бывает нужно) лучше использовать {} — проще модифицировать программу. Да и AnyCondition бывает достаточно сложным, со скобками, да и многострочным. Так что 2). Хотя при быстром написании (посколько VC не делает автоматически {}) иногда получается вариант 1).
А>Какой стиль выбрать ? Мне кажется стиль 2 намного удобнее.
Здесь очень трудно говорить какой из стилей удобней, т.к. все сугубо индивидуально. Но, например, когда входишь в новую команду ,а у них уже куча кода с одним стилем (например с первым), то хочешь или не хочешь, а придется писть используя второй.
Это и есть самое главное в любых стилях — главное постоянство. Потому что любой программер привыкнет к чтению даже самого отвратного стиля, но если он будет использоваться на протяжении всего проекта.
Здравствуйте OlegO, Вы писали:
OO>Предлагаю всем вместо приведения различных ситуаций, почитать книгу Ален И.Голуб "Правила программирования на С++", там этой теме целая книга посвещена, с примерами и аргументами.
Где-то в этом же треде я уже предлагал разместить ее на сайте, чтоб далеко не ходить...
Здравствуйте Aquary, Вы писали:
A>Здравствуйте OlegO, Вы писали:
OO>>Предлагаю всем вместо приведения различных ситуаций, почитать книгу Ален И.Голуб "Правила программирования на С++", там этой теме целая книга посвещена, с примерами и аргументами.
A>Где-то в этом же треде я уже предлагал разместить ее на сайте, чтоб далеко не ходить...
Да это было бы прикольно, К кому обращаться с просьбой это сделать
В принципе нет существенной разницы между этими двумя вариантами.
Мне приходилось пользоваться обоими (один предпочитал я, другой
в одном из проектов был требованием заказчика).
Если хотите для себя выбрать один из них — руководствуйтесь
своими эстетическими соображениями. :) Главное — не менять
выбранный стиль от модуля к модулю. ;)
Кстати говоря, мне сейчас более импонирует третий вариант,
по наглядности превосходящий оба предыдущих:
class Test
{
public Test()
{
// Initialize instance
m_iCurrentInstance = m_iTotalInstances++;
}
public int getInstanceNumber()
{
return m_iCurrentInstance;
}
private static int m_iTotalInstances=0;
private int m_iCurrentInstance;
}
Здесь каждый блок кода имеет заголовок и тело. Тело
оформляется отступом. Такое оформление позволяет лучше видеть
структуру кода (сначала, конечно, несколько непривычно,
но быстро привыкаешь и начинаешь ощущать преимущества такого стиля).
Кстати, AFAIR этого у Голуба нет. Есть у МакКоннелла:
McConnell, Code Complete. Это существенно более
интересная книжка, чем Голуб. И более толстая. :)
Regards,
Vladimir
Re[2]: Мои пять копеек. Re: Стиль программирования
VK>Здесь каждый блок кода имеет заголовок и тело. Тело VK>оформляется отступом. Такое оформление позволяет лучше видеть VK>структуру кода (сначала, конечно, несколько непривычно, VK>но быстро привыкаешь и начинаешь ощущать преимущества такого стиля).
Отступ — 4 символа, ОК? А то ретяешься... сегодня копался в коде одного... умельца... такие такие же отступы стояли... Жуть!
VK>Кстати, AFAIR этого у Голуба нет. Есть у МакКоннелла: VK>McConnell, Code Complete. Это существенно более VK>интересная книжка, чем Голуб. И более толстая.
A>Отступ — 4 символа, ОК? А то ретяешься...
Чего делаешь? :)
A>сегодня копался в коде одного... :crash: умельца... A>такие такие же отступы стояли... Жуть!
Я предпочитаю 2. 1 и 4 — это крайность. А 2 — золотая середина. :)
А вообще что 2, что 4 — нет большой разницы, как только привык к какому-либо
варианту, другие раздражают.
VK>>Кстати, AFAIR этого у Голуба нет. Есть у МакКоннелла: VK>>McConnell, Code Complete. Это существенно более VK>>интересная книжка, чем Голуб. И более толстая. :)
A>URL?
Насколько я знаю, ее нет в Инете. Во всяком случае ни я, ни еще несколько человек
ее не нашли. На Амазоне можно найти по названию.
Regards,
Vladimir
Re[4]: Мои пять копеек. Re: Стиль программирования
Здравствуйте Vladimir_K, Вы писали:
A>>Отступ — 4 символа, ОК? А то ретяешься... VK>Чего делаешь?
Теряешься
A>>сегодня копался в коде одного... умельца... A>>такие такие же отступы стояли... Жуть! VK>Я предпочитаю 2. 1 и 4 — это крайность. А 2 — золотая середина. VK>А вообще что 2, что 4 — нет большой разницы, как только привык к какому-либо VK>варианту, другие раздражают.
С 2 все сливается, особенно если не стоят комментарии после закрывающих скобок
Re[5]: Мои пять копеек. Re: Стиль программирования
От:
Аноним
Дата:
15.08.02 06:38
Оценка:
Здравствуйте Aquary, Вы писали:
A>Здравствуйте Vladimir_K, Вы писали:
A>>>Отступ — 4 символа, ОК? А то ретяешься... VK>>Чего делаешь? :) A>Теряешься :shuffle:
:) А я было подумал, это какая-то жаргонная калька с английского.
VK>>Я предпочитаю 2. 1 и 4 — это крайность. А 2 — золотая середина. :) VK>>А вообще что 2, что 4 — нет большой разницы, как только привык к какому-либо VK>>варианту, другие раздражают.
A>С 2 все сливается, особенно если не стоят комментарии после закрывающих скобок :crash:
Не знаю-не знаю... Конечно, если методы по два экрана размером, то такая проблема может иметь место. Но это же ненормально. :) А если метод в 5-7 строк, то ничего никуда не потеряется. :)