зависит от языка

Насколько я понимаю, в языках где великая и маленькая буквы различаются разницы в именах нет.
Интересует в первую очередь C/С++.

Каждый использует тот вариант, который он выбрал. Лично я использую Qt coding style, но немного переработанный под меня.

1.Переменная

а) int someVar;

1.1 'Временные' переменные К примеру:
Как вы именуете переменную _var ?

varVal, varRef, etc

3. #define
Насколько я понял, в С/С++ есть некоторое правило, по которому все что записано в #define пишется с большой буквы?

Смотря что обозначать директивной препроцессора.

4. Константы.
в define или в .h файле как static <type> x0=0?

Константы дефайном - моветон и говно. Константы в .h файле - тоже.

6. Как с точки зрения удобства/читаемости кода оставлять одно- двострочные коды в .h файл?

За код в .h надо бить утюгом по пальцам. Ибо нехуй в интерфейсе класса писать реализацию. Нужен inline - пиши inline.

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

7.Запись в одну строку небольшого кода:

Не нужно

8. Пробелы:
Некоторые ID ставят пробелы, например напишут 'a = _a + 1; b = _b; c = a + b + _c;'

И я в т.ч. От когда без пробелов тянет блевать

9. Небольшой класс/структура/..
К примеру, есть класс (class1), записанный в .h и .cpp файлах. Он использует LittleClass, описание которого занимает 10-15 строчок (если все написать в .h файле), причем littleclass больше нигде в проекте не используется. Есть ли смысл выносить LittleClass в отдельный файл??

Есть смысл объявить определить этот LittleClass в .cpp файле, а в .h чтобы о нём было ни слуху ни духу

10. Комментарии.
Как лучше вставлять однострочные комментарии:

Похрену. Предпочитаю /*comment*/

В питоне же все довольно жестко регламентировано через PEP.

Есть смысл объявить определить этот LittleClass в .cpp файле

А если нужно

class class1{ LittleClass a; /*...*/ }

Тогда как написать в .cpp файле?

За код в .h надо бить утюгом по пальцам.... Нужен inline - пиши inline.

К примеру, int get_a() {return a;} не занимает места, а если писать в .cpp файле выйдет

int className::get_a()
{
return a;
}

Константы дефайном - моветон и говно. Константы в .h файле - тоже.

В .cpp?

А если нужно

class class1{ LittleClass a; /*...*/ }

Тогда не выйдет. Но лучше сделать LitteClass вложенным и приватным.

Ну или использовать pImpl, тогда выйдет.

В .cpp?

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

К примеру, int get_a() {return a;} не занимает места, а если писать в .cpp файле выйдет

Тебе места жалко чтоли? Или ты код одним пальцем набираешь?

За код в .h надо бить утюгом по пальцам. Ибо нехуй в интерфейсе класса писать реализацию. Нужен inline - пиши inline.

Вот когда темплейты перестанут быть макросистемой и станут полноценными дженериками - будем писать весь код в .cpp, а пока, товарищ Рабинович, не выпендривайтесь.

темплейты

Это отдельный случай, ТС про это вообще ничего не писал.

В этом случае, всё равно я против кода в объявлении класса. Код методов в .h можно и ниже написать.

С. Макконнелл «Совершенный код» же.

Добавил 11 пункт.

С. Макконнелл «Совершенный код» же.

Спасибо, почитаю.

Лично я использую Qt coding style, но немного переработанный под меня.

Дай угадаю: int* someVar вместо int *someVar? А вообще я тоже его использую.

Клёвый опрос
В целом в С++ юзаю Qtшные стандарты.

1.a)

1.1.какие-нибудь однобуквенные названия

2.d)class MyClass{};

3. Да, но дефайны не использую

4. Константами

5.с) doSomeButton, exitButton, progNameLabel

6.Всё равно на отдельную строку кидаю, читабельней.

7.Склоняюсь ко второму.

8.Питоновский способ - пробелы вокруг операторов и возле запятых.

9. Думаю нет.

10.а) быстрее.

11.в каких-то средах есть специальные прагмы(или как они там называются), в еклипсе точно todo и fixme.

4. Константами

В .h или .cpp файле?

наверное лучше в .cpp, ибо зачем эти имена в других местах.

Дай угадаю: int* someVar вместо int *someVar? А вообще я тоже его использую.

Не угадал. :)

смотри кодингстайлгайд для своего проекта и не парь людям мозг. ты бы ещё про размер буковок на клавиатуре спросил.

ты бы ещё про размер буковок на клавиатуре спросил.

А каков у вас размер буковок?

кодингстайлгайд

Что это?

Собственно вот.
1. Camel Case, первая маленькая: myVar;
1.1. Редко использую префикс «_». Обычно просто myVar.
2. Класс начинается с большой буквы: MyClass
3. #define избегаю и тебе советую
4. Константы не следует объявлять глобальными. Использую const.
5. Кнопки - это объекты, а не действия. exitButton, applyChangesButton.
6. В .h вообще не пишу реализацию. Даже однострочную.
7. В две строки.
8. Только с пробелами.
9. 1 класс = 1 файл.
10. Посмотри doxygen.
11. Посмотри doxygen.

А вообще читай Стива Макконнелла. А то здесь обычно советуют всё, кроме него. :)

3. #define избегаю и тебе советую

Почему??

ymuv

Почему??

Я про C++, если что. А зачем они тебе?

java:

1 a
1.1 : tempVar
2 MyClass
3 -
4 public static final
5 <something>Button
6 -
7 2й
8 пробелы ставлю
9 выношу (если только не анонимный класс)
10 a
11 смотря что и как исправить

В этом случае, всё равно я против кода в объявлении класса. Код методов в .h можно и ниже написать.

А смысл?

11 смотря что и как исправить

А если написать и потом вернуться, то как делаете? Не в памяти же держать.

Чаще всего пишу TODO: <текст комментария>
NetBeans ищет все такие TODO-комментарии и заносит в список Tasks. Но это NetBeans, java...

Наверное чтоб удобно было читать, хотя (мое ИМХО) однострочный код не засоряет код. (если притом написанный в одну строку с методом)

Еще добавлю, что после if/for/... всегда оборачиваю блок кода в скобки, даже если кода там - 1 строчка.

// так:
if (foo) {
    bar();
} else {
    bar2();
}

// но не так! :
if (foo)
    bar();
else
    bar2();

1.1 'Временные' переменные К примеру:

ObjC:

var - для property _var - для переменных внутри класса var_ - для переменных внутри метода

Java:

усе var

Но никогда не пишу some_var ибо говно на вид и писать дольше. Лучше someVar.

2. Класс.

Классы называю всегда начиная с заглавной буквы. MyClass. Никогда не использую подчеркивание в имени класса, только префиксы. Например MAClassName, где MA - абривиатура от My App.

За это +. Ненавижу товарищей которые не ставят кавычки. Ничетабельно нифига, да и ошибку допустить намного легче. Потом сиди и думай почему у тебя условие сработало.

Да и для Java есть Code Conventions - http://www.oracle.com/technetwork/java/codeconvtoc-136057.html

Вот их стоит придерживаться.

А смысл?

Интерфейс не засорять, очевидно же, ну.

Я все читать не стал, но - так, чтоб было понятно вообще что это и куда это, ну и в зависимости от языка, конечно.

Все переменнные и объекты - со строчной буквы. Имена _любых_ типов и синонимов - с прописной. Остальных символов регистр не имеет значения.

Все константы, дефайны и макросы - полностью UPPER_CASE.

> 5. Именование кнопок/label Крайне зависит от контекста. В общем случае - не имеет значения.

>9. Небольшой класс/структура/.. Имеет смысл выносить, только если таких лилипутов наберётся десяток.

>11. Как вы оставляете коментарий, что к этому участку кода нужно вернуться и что-то исправить? // TODO vim услужливо подсвечивает.

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

1) b) int some_var;

Я так привык. Это уже не выбить.

1.1) int tmp_var;

Это тоже привычка. А начинать имя переменных с подчёркивания я отучился с самого начала.

2) Классы. Пару лет работал в конторе, которая всё писала на С++. Там стандартом было имя класса mySmallClass - так и писал.

3) В С define - только заглавные буквы. В С++ define крайне не рекомендую (и не только я).

4) Зависит от языка (С или С++) и от принятого в твоей конторе стиля кодирования.

5) В основном вариант а)

6) С таким мало сталкивался, но это мне не нравится. Имхо, лучше применять в таких случаях inline-функции.

7) В одну строчку пишу тогда и только тогда, когда и условие, и тело очень короткие. В последнее время стал всё чаще отказываться от однострочной записи.

8) Для меня пробелы обязательны. То, что ты показал, это очень плохо читается. Рекомендую пользоваться пробелами.

9) (нет ответа)

10) Как сишник (преимущественно), предпочитаю /* комментарий */, как более привычный (руки сами на автомате вбивают слэш со звёздочкой :). Хотя иногда и // пользую.

11) Всегда и везде пишу:

fun1();
fun2(); // TODO: и краткое объяснение, что и почему надо исправить

Всё написанное выше относится в основном к С и в отдельно оговоренных случаях к С++.

Дополнения

К пункту 3:

Весьма часто enum удобнее и логичнее, чем пачка define-ов.

Общее:

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

В плюсах вынесение кода из шаблонного класса не очищает интерфейс, а обедняет его. Если не видеть кода, то непонятно, какие требования предъявляются к аргументам шаблона, и какие методы будут сгенерированы для каких аргументов. Это ж не дженерики.

Да, кстати, мои предпочтения:

1) Переменная — myVar

1.1) Временная переменная — tmpVar

2) Класс — MyClass

3) Макрос — MY_MACROS (пользовался только в одном проекте — сделал своего рода мини-рефлекшен)

4) Константа — если целочисленная, то enum, если более сложная — то static

5) Кнопка — myButton

6) Однострочная функция в .h-файле — нормально, если можно уложить в ту же строку, что и объявление функции; двухстрочная — уже много

7) Однострочный код — сам предпочитаю так, мне за строчки не платят

8) Пробелы — в простых выражениях не ставлю, чуть сложнее — иногда ставлю (int t = a*b + c*d), порой вспоминаю статью Страуструпа про перегрузку оператора «пробел».

9) Вспомогательные классы пишу рядом с основными, либо вообще в .c-файле, если можно. Люблю локальные классы, но пункт в стандарте о том, что они не могут, видите ли, быть аргументами шаблонов, у меня вызывает только раздражение.

10) Комментарии — //, если это целая строка или конец строки. Исключение: если я временно комментирую маленький кусочек кода, то использую /**/

11) // TODO

Как лучше вставлять однострочные комментарии:

Как емакс сделает, так и оставляю.