Можно и 120, но на маленьком мониторе будет неудобно читать.

Функции, не влезающие в экран --- ещё большее зло. Хотя, я слышал, некоторые товарищи поворачивают монитор на 90 градусов --- и тогда многие функции начинают влезать в экран. Но это, имхо, извращение.
Хотя очень длинные строки (>120)--- действительно зло.  Но они обычно и не встречаются, так как в большинстве IDE слева и/или справа обычно находятся панели навигации (class view, file tree, opened files, и.т.д.), отладчика, и т.д.

Увеличивающая количество строк в функции.

Qt.

Нет, за длиной как строк, так и функций никто особо и не следит, просто все пишут так, как самим удобнее. И оказывается, что на большом мониторе лимит 80 символов является излишним.

И то, что код чрезмерно длинной функции тяжело читать.

Длины строк --- это не самый решающий фактор, влияющий на бардак в коде.

У меня как-то всё помещается на экране. Да, когда открыты все панели отладчика, то они иногда закрывают часть кода, но настолько длинные строки как-то редко встречаются. А в качестве терминала я использую yakuake. Зачем мне его постоянно держать на экране?

Это и в плюсах все нормальные люди пишут в 2 строки. One line --- One statement. И дело здесь не в читаемости кода, а в том,  что на строку можно поставить breakpoint, а на кусок строки нельзя.

Кто бы спорил, но вот утверждение, что лимит в 80 символов --- необходимое условие читаемости объективным никак не является.

Не должна. Но вот только не всегда она улучшит читаемость.

Если полдюжины, то я и не спорю. А вот если 3, то иногда уместнее написать одну строку длиной 100 символов, чем 3 длиной 60.
Кстати, почему «тем более»? Чего такого особенного в плюсах?

Стандарты везде разные. В частности, там, где я пишу код, длина строки вроде как не лимитирована (в пределах здравого смысла, конечно: если сделать строку в 200 символов, то я думаю, что это никому не понравится --- и мне в том числе).

Ну, когда я буду писать что-то открытое, то я об этом подумаю. Но скорее всего, сделаю лимитом 100 символов, а не 80.

Можно. Но у меня редактор или IDE всегда находится на отдельном рабочем столе, на котором больше ничего не открыто. Единственное исключение --- там может быть открыта отлаживаемая программа. И иногда таки и программа, и IDE открыты одновременно. Но 80 символов в строке в этом случае не спасут.

В Google Style guide есть такой пункт:
You may diverge from the rules when dealing with code that does not conform to this style guide. <...> Use common sense and BE CONSISTENT. В соответствии с этим правилом наш спор теряет подобие всякой осмысленности.

Вот как раз на строку, содержащую return очень даже есть смысл.

Во втором примере --- скорее всего, да. В первом --- не всегда.

Мне не наплевать, просто я иначе расставляю приоритеты. Если бы кому-то другому это было бы принципиально, я думаю, появилось бы правило, запрещающее длинные строки.

Почему? Если в проекте есть длинные строки, то с какого перепугу я должен ограничивать себя 80-ю символами?

Про python не скажу, а в C++ очень даже есть. То есть я хочу проверить, какого чёрта он выходит из функции в этом месте. У меня два варианта --- поставить условный breakpoint на строку, содержащую if, либо поставить обычный breakpoint на строку с return'ом. Лично мне больше нравится второй вариант.

Второй пример вовсе даже не смешон, если параметров штук 12, а вместе с комментариями в тех же строках получается порядка 100 символов. Если разместить все комментарии на отдельных строках, то количество строк в одном только прототипе функции увеличится в два (!) раза.

Этот комментарий является очень существенным в случае, когда параметров много и передаётся константа (например, 0, как там). Без этого комментария тяжело понять, в качестве какого аргумента передаётся 0.

Поменьше курить надо --- вредно для здоровья А вообще всё зависит от правил. Если есть правило «нельзя бросать окурки на тротуар», то тогда нужно выбрасывать в урну. А если такого правила нет, то тут всё зависит от идеологических убеждений того, кто бросает. Если он считает это нормальным --- пусть бросает. Если не нравится --- может бросает в урну. Главное --- чтобы не забывал потушить окурок прежде чем бросить: в урне могут быть легко воспламеняющиеся предметы. Аналогия ясна?

http://astyle.sourceforge.net/astyle.html еще есть.

Я сейчас интересуюсь этим направлением, потому что удаление одних циклов и добавления других очень карёжит код и после коммита можно пробела или таба недосчитаться, что порой бесит (лишняя разница при коммите).

http://sourceforge.net/projects/uncrustify/

http://sourceforge.net/projects/gcgreatcode/

http://www.gnu.org/software/indent/manual/indent.html оказывается есть - там не только GNU-style, который многим не нравится.

Отредактировано Keepun (28-05-2012 00:54:37)

А что не так?

Естественно, когда аргументов дюжина, то они будут на отдельных строках. Комментарии при вызове функции идут только в тех строках, где название передаваемой переменной не говорит само за себя (например, если это константа 0).

Обоснуйте, чем это плохо.

Только вот не надо выдирать фразы из контекста. Я же ясно написал:

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

Насколько я понял, эта штука не меняет код. Она просто проверяет, есть ли в нём несоответствия некоторым формальным правилам, и если есть, то не даёт закоммитить.

С http://sourceforge.net/projects/uncrustify/ мне теперь все равно какой стиль кода у проекта, потому что все перегоняется под мой стиль и обратно.

Uncrustify Code Beautifier поддерживает ~410 опций, так что подобрать стиль проекта можно. Да и перегонять обратно нужно только измененные файлы.

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

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

LinuxMint  13  Mate  отлично работает !