1) Давно выбрал и использую постоянно http://www.rsdn.ru/article/mag/200401/codestyle.XML
2) Комментариями частенько отделяю обособленные куски кода, которые, тем не менее, не достойны быть оформлены отдельным методом. Стараюсь комментировать так же сложные для меня моменты, которые будет сложно понять через месячишко.
3) См. пункт 1. Ничего лишнего.
4) Стараюсь соблюсти баланс между собственными кривыми руками, удобочитаемостью, удобомодифицируемостью кода и какой-никакой эффективностью.
5) VS11 без расширений

>>8790

>Не используйте подчеркивание для отделения слов внутри идентификаторов, это удлиняет идентификаторы и затрудняет чтение. Вместо этого используйте стиль именования Кемел или Паскаль.

В бидоне например есть пеп8 со своими требованиями когда применять андерскор, а когда что-нибудь еще. Это все зависит от языка.

>Старайтесь делать имена идентификаторов как можно короче (но не в ущерб читабельности). Помните, что современные языки позволяют формировать имя из пространств имен и типов. Главное, чтобы смысл идентификатора был понятен в используемом контексте. Например, количество элементов коллекции лучше назвать Count, а не CountOfElementsInMyCollection.

Автор Code Complete (одна из лучших книг про дизайн программ) с ним бы не согласился. Каунт чего? А если у меня этих каунтов несколько?

The optimum length for a name seems to be somewhere between the lengths of x and
maximumNumberOfPointsInModernOlympics. Names that are too short don't convey
enough meaning. The problem with names like x1 and x2 is that even if you can
discover what x is, you won't know anything about the relationship between x1 and x2.
Names that are too long are hard to type and can obscure the visual structure of a
program.
Gorla, Benander, and Benander found that the effort required to
debug a program was minimized when variables had names that
averaged 10 to 16 characters (1990). Programs with names averaging 8 to 20 characters were almost as easy to debug. The
guideline doesn't mean that you should try to make all of your
variable names 9 to 15 or 10 to 16 characters long. It does mean
that if you look over your code and see many names that are
shorter, you should check to be sure that the names are as clear as
they need to be.
You'll probably come out ahead by taking the Goldilocks-and-the-Three-Bears approach
to naming variables, as Table 11-2 illustrates.

Table 11-2. Variable Names That Are Too Long, Too Short,
or Just Right

Too long: numberOfPeopleOnTheUsOlympicTeam
numberOfSeatsInTheStadium
maximumNumberOfPointsInModernOlympics

Too short: n, np, ntm
n, ns, nsisd
m, mp, max, points

Just right: numTeamMembers, teamMemberCount
numSeatsInStadium, seatCount
teamPointsMax, pointsRecord

Дальше твою ссылку не читал.

>>8793
1) Ты конечно же заметил, что я пишу на C#, и та ссылочка справедлива только для шарпа? Питон ("бидон"?) я видел только на картинках.
2) Code Complete является истиной в последней инстанции только для тех, у кого своей головы нет. Если разработка полностью ведется в VS (у которой есть всплывающие подсказки о типе переменной), то имеет смысл использовать Count для типа TeamMember вместо всяких teamMemberCount, потому что и так ясно, о чем идет речь. Для C/C++ teamMemberCount уже будет лучше. Особенно, если писать код в vim, emacs или что там еще есть у линуксоидов.
Не подгоняйте все под одну гребенку, мсье.

Мне нравится ставить префикс m_ перед членами класса, а то не понятно где просто переменная, а где мембер.

>>8795
у тебя у переменных "говорящие" имена типа "set[Insetrvariablenamehere]"?

Я где то слышал, что можно без геморроя различать их, если называть функции "действиями" а переменные существительными.

>>8810
Называть переменные глаголами, а функции существительными в голову никогда не приходило. И как это относится к префиксам?

>>8813
Ну, обычно и так понятно, где переменная а где функция же? Или существует хитрое вуду (кроме препроцессорного макроса), которое при вызове из объекта некого поля, обращается вместо него непонятно куда?

>>8816
А причем тут функции? Я только про переменные говорил. Представь, что есть член класса Position и в каком-то методе тебе нужна локальная переменная с позицией. Как назвать? Лепить префиксы/постфиксы? Писать с маленькой буквы? Бред. Городить огороды ради такой простой вещи не нужно, если поле класса назвать m_Position, можно спокойно создавать другие переменные с таким же назначением не коверкая названия, плюс одного взгляда достаточно, чтобы было ясно кто есть кто. Не ошибешься, нечаянно пропустив this и не запутаешься с такими одинаковыми именами.

>>8789

Я, конечно, далеко не шри, не гуру и не джи, но вот как я делаю:

1. На работе - доморощенный, дома - другой доморощенный. Может, они как-то научно называются, но я этого не знаю. На работе фигурные скобки расставляю в K&R стиле, дома - с новой строчки. На работе названия функций и переменных в сишном коде - маленькими буквами через подчеркивание, к именам типов добавлено _t, в плюсовом - названия классов, структур, функций, методов и свойств - camelCase. Дома я что в С, что в плюсах переменные и свойства обзываю маленькими буквами через подчеркивание, методы и функции - camelCase, классы и структуры - CamelCase. Отступы на работе 4 пробела, дома 2. Вообще, в стандарте главное, чтобы его соблюдали все, пишущие данный код. Иначе код начинает выглядеть как говно.
2. Комментирую места, которые писались "чтоб быстро и работало", что их надо переписать при первой возможности. Еще неочевидные места в алгоритмах, сделанные для оптимизаций. Плюс TODO, если какая умная идея пришла, а реализовать времени нет.
3. Особого стиля нет.
4. У меня в редакторе автоформатирование, но стараюсь сразу делать красиво.
5. Читать много хорошего кода думая, писать много кода думая.
6. Vim, стандартная гамма.

А вообще, почитай "Ремесло программиста" Питера Гудлифа, там он хорошо расписал и про комментарии, и про стандарты, и про то, чем хороший код отличается от плохого.

>>8873

Никогда не мог понять почему K&R так популярен, когда код на нем куда труднее читать чем код форматированный в стиле Олмана, особенно если там многоуровневое вложение.
http://en.wikipedia.org/wiki/Indent_style#K.26R_style
http://en.wikipedia.org/wiki/Indent_style#Allman_style

>>8878
Линуксонищим не понять. Компактнее - легче читать.

>>8879

Возможно для тебя это будет новостью, но это базовая функция подсветки не эксклюзивная для твоего виндоус добра. Алсо К&Р были виндузятники, угу.

>>8879
> это базовая функция подсветки
О какой подсветке речь? У меня на скрине линии, обозначающие блоки. Причем тут подсветка? Подсветка чего? Пробелов? И ты так и не назвал где же такая функция присутствует. Не стесняйся, желательно со скрином.

>>8881

Например, вим с плагином indent guides. Или sublime text.

>>8882
Ух, блин. Я надеялся, что в текстовом режиме это будет выглядеть максимум страшно, или покажешь какой-нибудь гуевый редактор за который настоящие линуксоиды опустят. Твоя взяла. :3

>>8881

Скрин дал не я кстати, это еще один анон. Алсо да, это называется ident guides и довольно обычная фича, хотя иногда по умолчанию отключена.

>>8789
https://www.systutorials.com/docs/linux/man/7-npm-coding-style/