[Kabdim 0]

+1 за гугльстайл. Самый вменяемый стайлгайд на данный момент. Для любителей варианта "от создатаелей..." даже Страуструп написал тяжеловесный толмуд. А вот придумывать своё в 17 году - это жесть, ей богу.

[juvf 10]

+1 за гугльстайл. Самый вменяемый стайлгайд на данный момент.

string table_name; // OK - uses underscore.

string tablename; // OK - all lowercase.

 

string tableName; // Bad - mixed case.

 

где уж самый вменяемый? tableName - читабельно. table_name - читабельно. tablename - не читабельно. tableName - такой стиль часто встречал. Например Qt так написан. Например переменная

bool QGuiApplication::quitOnLastWindowClosed, в гуглсайле будет так quitonlastwindowclosed - это плохо читаемо. имхо.

 

 

[Forger 17]

quitonlastwindowclosed - это плохо читаемо

Поддерживаю! Такой набор букв даже носители языка вряд ли прочтут без труда, остальным остается лишь по-сочувствовать ))

 

[Kabdim 0]

tablename - не читабельно

Как по мне так вполне читабельно, особенно если это не просто два слова, а постоянно используемые в такой связке два слова. Рекомендаций называть переменную предложением, а потом записывать её имя без подчеркиваний там нет.

 

А по поводу вашего примера: bool QGuiApplication::quitOnLastWindowClosed - не переменная, а property. В гугльстайле вы модификаторы property можете называть как переменную, но это не требуется. Т.е. когда имя property - предложение, очевидно её удобней называть Camal case'ом, что стайл вполне позволяет.

[Forger 17]

Как по мне так вполне читабельно, особенно если это не просто два слова, а постоянно используемые в такой связке два слова.

Полагаю, что если жить только с гуглекодом и изучать/пользовать/читать только гуглепроеты с утра до вечера, то постепенно привыкаешь и подсаживаешься :rolleyes:

Однако, если пройдет какое-то время (перерыв), то придется заново вкуривать в этот код, потратив некоторое время на повторное привыкание.

 

Существуют книги, написанные так, что читаются на одном дыхании - как бежишь под ровной дороге,

но попадаются такие, что "спотыкаешься" на каждом слове, словно бежишь через непролазный лес.

Гуглестиль, имхо, больше относится ко второму, нежели к первому )))

[Aaron 1]

К чему холивар, Kabdim? Главное не инструмент (коих много), а цель - достичь переносимости и поддерживаемости кода в команде. Если тебе инструмент не подходит - ты берёшь другой, или делаешь удобный, под себя.

А вот придумывать своё в 17 году - это жесть, ей богу.

В чём именно жесть? Скомпилировать несколько трудов, взять из них лучшее, вычеркнуть неудачное и лишнее, скомпоновать - это здорово!

Между прочим, разработчики крупных проектов не стесняются внедрять свои собственные правила, поищите JPL C Coding Standard, CERN C++ Coding Standard

ГуглоСтайл как по мне, не совсем торт. Аналогично как и КьютСтайл. Выше уже высказались.

[Kabdim 0]

Извиняюсь, если мои посты вызвали ощущение холивара, его там нет.

Мой поинт в том что пользы от унификации для большинства команд и проектов больше чем от кастомизации. Т.е. если взять популярный codestyle можно во-первых не набивать свои шишки на неочевидных вещах, во-вторых читать сторонний код в этом codestyle как свой/вносить правки не перестраивая свой мозг лишний раз. А различных крупных codestyle'ов много, можно выбрать то что ближе.

Крупные проекты очевидно являются исключением, т.к. их крупность позволяет авторам таких проектов создать тонко настроенные инструменты под свои задачи. И при этом затраты на разработку и переучивание программистов будут ниже чем польза.

[Forger 17]

И при этом затраты на разработку и переучивание программистов будут ниже чем польза.

Затраты на переучивание? Не смешите ))) Если программер не умеет читать чужой код, то его бесполезно переучивать :smile3046:

 

Дело тут в другом - крайне затратно вынуждать опытного программиста писать и отлаживать свой код в стиле чужого кривого кода, к тому же далеко не каждый профи на это подпишется.

[Kabdim 0]

Затраты на переучивание? Не смешите ))) Если программер не умеет читать чужой код, то его бесполезно переучивать

Выходит codestyle вообще не нужен?

Дело тут в другом - крайне затратно вынуждать опытного программиста писать и отлаживать свой код в стиле чужого кривого кода, к тому же далеко не каждый профи на это подпишется.

Не понял, вы другими словами повторил то что я сказал, но при этом возразили. :)

[Forger 17]

Выходит codestyle вообще не нужен?

Конечно, дисциплина в коде и документации нужна!

Но только в том случае, если она ориентирована под максимальное кол-во народу, а не под уникальных мега-ботанов, которые сходу способны читать такие названия правильно:

quitonlastwindowclosed

:)

 

Не понял, вы другими словами повторил то что я сказал, но при этом возразили. :)

Повторюсь: "крайне затратно вынуждать опытного программиста писать и отлаживать свой код в стиле чужого кривого кода".

Под словом "кривой" я подразумеваю код, реализованный в "кривом" стиле, который выдуман "с потолка", в стиле "изобретаем велосипед".

[Kabdim 0]

Нужен, если он создан под максимальное кол-во народу, а не под уникальных мега-ботанов :)

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

 

Повторюсь: "крайне затратно вынуждать опытного программиста писать и отлаживать свой код в стиле чужого кривого кода".

Под словом "кривой" я подразумеваю код, реализованный в "кривом" стиле, который выдуман "с потолка", в стиле "изобретаем велосипед".

Чем публичней и распространенней стандарт тем меньше он кривой? И наоборот чем уже сфера пользователей тем он как минимум шероховатый.

[Forger 17]

Чем публичней и распространенней стандарт тем меньше он кривой? И наоборот чем уже сфера пользователей тем он как минимум шероховатый.

Все так, это - эволюция (извиняюсь за громкое слово).

Кривой стиль и соответственно говно-код не способны эволюционировать нормально.

 

Но нужно отличать коммерциолизированный стандарт (скажем, гугльстайл) и обычный - "бесплатный", который можно почерпнуть из книжек.

Бесплатный эволюционирует эффективнее, он гибче и потому жизнеспособнее, нежели платный ()

 

Но это все же пустая дискуссия, все одно каждый останется при своем мнении и при своем стиле :)

[juvf 10]

А по поводу вашего примера: bool QGuiApplication::quitOnLastWindowClosed - не переменная, а property.

А проперти - это не переменная? в с++ вообще нет проперти. проперти - это уже смысловое значение переменной или константы.

 

Q_PROPERTY([b]bool quitOnLastWindowClosed[/b]  READ quitOnLastWindowClosed WRITE setQuitOnLastWindowClosed)

вижу тип переменной bool, имя переменной quitOnLastWindowClosed. может в с++ появилось что-то новое, появились проперти.... заглянул в ассистант, глянул что такое PROPERTY

Q_PROPERTY(type name.....

ан нет... тип и имя переменной.

 

без разницы в каком стеле написано.... главное чтобы всем было понятно.... конечно в чужом стиле - непривычно, и лучше вырабатать стиль максимально приближенный к самым распространённым. моя шпаргалка и тут книжки выкладывали - приближены. что касается гуглстайла.... не разу не встречал его. камел кэйс используется во многих стилях. я глянул по диагонали гуглстайл.... нашел в гугл стайле то, что явно будет ухудшать чтение кода, а именно переменные quitonlastwindowclosed. есть там ещё, что, что будет мешать... не то к чему я не привык, а что будет мешать. я не привык к именам quit_on_last_window_closed, но это дела вкуса и привычки. такая переменная нормально читается. а вот quitonlastwindowclosed - это мешает. и не только мне не понравился гугл стайл.

 

ps в довершении.... в QtCreator, и позже в Eclipse, есть автодополнение по камел кейсу. назвал переменную quitOnLastWindowClosed, в коде набираешь qol (или qOL) автодополнение предлагает все переменные начинающиеся на q и имеющие в имени большие буквы O и L. в итоге будет предложены все переменные и методы... с вероятностью в 100% будет предложена переменная quitOnLastWindowClosed (или достаточно будет набрать qO). у QString набираешь tss - автодополнение делает toStdString. Набираешь gp - выдает getPoint и getPosition. tn - выскочит tableName Т.е. камел кэйс дает подсказку для автодополнения. Это очень удобно в написании.

 

[Kabdim 0]

Но это все же пустая дискуссия, все одно каждый останется при своем мнении и при своем стиле :)

Мнение, то у нас общее - стиль нужен, а вот вкусы и правда различаются. :)

А проперти - это не переменная?

Нет, у проперти может вообще не быть представления в виде закрытой переменной.

в с++ вообще нет проперти.

А в QT из которого выдран пример - есть.

без разницы в каком стеле написано.... главное чтобы всем было понятно....

Тут я с вами безусловно согласен.

и не только мне не понравился гугл стайл.

ps в довершении.... в QtCreator, и позже в Eclipse, есть автодополнение по камел кейсу. назвал переменную quitOnLastWindowClosed, в коде набираешь qol (или qOL) автодополнение предлагает все переменные начинающиеся на q и имеющие в имени большие буквы O и L. в итоге будет предложены все переменные и методы... с вероятностью в 100% будет предложена переменная quitOnLastWindowClosed (или достаточно будет набрать qO). у QString набираешь tss - автодополнение делает toStdString. Набираешь gp - выдает getPoint и getPosition. tn - выскочит tableName Т.е. камел кэйс дает подсказку для автодополнения. Это очень удобно в написании.

Тут тоже частично соглашусь, но это всё же особенности конкретного автодополнения, он мог бы точно так поступать и с разделением подчеркиваниями.

[juvf 10]

Тут тоже частично соглашусь, но это всё же особенности конкретного автодополнения, он мог бы точно так поступать и с разделением подчеркиваниями.

а оно работает по подчеркиванию. написал int hello_world; сохранил. в следующей строке написал hW и жамкнул ctrl+Пробел. дополнило до hello_world. я не говорю что подчеркивание не удобно, я говорю что слитно не удобно. а гугл пердлогает и слитно тоже.