[c++] Этика написания кода

Уникальное перечисление вариантов, где нет ни одного правильного по любому вменяему стилю кодирования. Это как так у вас получилось, признавайтесь?

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

Эм... я не ставил целью перечислить все варианты (их тут порядка полусотни же), просто привёл несколько примеров, чтобы пояснить, о чём я говорю. Сам бы применил вот такое:

if (a == b)
   ++b;

Код пишу (пока) для себя, но хотелось бы таки знать, как обычно поступают. Есть же большие проекты навроде ядра, там как написали бы?

Вон в тех программах на C#, что я видел, в именах повсеместно используют CamelCase, причём переменные именуют с маленькой буквы, а классы с большой.

Предпочитаю третий вариант, только ++b.

упс

писать на C++ неэтично по определению :)

http://www.williamspublishing.com/Books/5-8459-0859-0.html

Мой вариант:

if(a == b)
    b++;

:)

а если так:

(a == b) ? b++ : b;

этично? :)

KDE — коротковато;

Kernel — много всего, но про C (а классы, методы и т.п. как именовать?);

цитата про еретиков :)

There are heretic movements that try to make indentations 4 (or even 2!)

possibility.com — какая-то ересь с CamelCase.

Также интересует этика размещения комментариев к классам и функциям, к действиям. То, что комментарии С99 (//) во многих кругах не любят, я уже понял.

Кстати, насчёт итераций. В разговоре со мной один мехматянин как-то давно утверждал, что при ++i операций с памятью происходит на одну меньше, чем при использовании i++. Соответственно, если оно не важно, лучше использовать ++i. Это он правду сказал, или напутал чего?

>при ++i операций с памятью происходит на одну меньше, чем при использовании i++

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

http://www.kernel.org/doc/Documentation/CodingStyle

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.

:)

Вообще, на kernel.org мне всё нравится. Вот, например, полезный совет оттуда — использование out в функциях:

int fun(int a)
{
	int result = 0;
	char *buffer = kmalloc(SIZE);

	if (buffer == NULL)
		return -ENOMEM;

	if (condition1) {
		while (loop1) {
			...
		}
		result = 1;
		goto out;
	}
	...
out:
	kfree(buffer);
	return result;
}

Осталось чуть подробнее разобраться со стилем комментирования (где, как, когда, сколько). И с классами.

>почему не принято использовать CamelCode
Это в C++ то camelCase не используют? Помоему, в C++ его как раз очень таки используют. И в Qt, и даже в оффтопике это стандартный стиль именования в C++.
В бусте, разве что, через подчеркивания.

В чистом Це - может быть и не используют особо, но в Це.

>Encoding the type of a function into the name (so-called Hungarian notation)

это Системная Венгерская, к оригинальной Венгерской не имеющая никакого отношения

http://www.joelonsoftware.com/articles/Wrong.html

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

И пишите больше. Ощущение где надо писать комментарии придет с опытом.

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

В чистом Це - может быть и не используют особо, но в Це.

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

Вот так пойдёт?

• все переменные — с маленькой буквы;
• все константы — только большими буквами;
• имена классов и типов — с большой буквы;
• вместо подчерков начинать новое слово с большой буквы.

Уже говорил — пока пишу для себя. Через месяц будем писать более-менее крупный проект втроем. Я, препод и ещё один студент. Причём препод особого участия принимать в кодинге не будет (ну разве что поначалу... а так с него в первую очередь формулы и прочее), да и стиля у него нету. А мы, студенты, вообще в программировании нули почти, займёмся этим в том числе чтобы опыта набраться.

> http://www.williamspublishing.com/Books/5-8459-0859-0.html

Как доосилю Страуструпа, надо будет эту книжку посмотреть. Отрывки интересными показались.

Я бы написал так.

if (a == b) {
    b++;
}

Константы - большими буквами, типы начинаются с заглавной, все остальное - lowerCamelCase.

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

Использование goto в приведенном случае, думаю, обосновано, но сам не пользуюсь им из принципа.

Была книга.. Кажется, Ален Голуб - «Правила программирования на С++». Там, если не ошибаюсь, было и про стиль кодирование и про комментарии.

Использую Java Coding Conventions во всех С-подобных языках, просто чтобы не заморачиваться.

> Сходите в оперу, театр. Хотя бы в классическую картинную галерею.
facepalm.jpg

Coding Convension - обязательная вешч в комманде прграммёров.
Необходимо, чтобы код был не различим вне зависимости, кто его написал.
У нас используется:
http://root.cern.ch/drupal/content/c-coding-conventions

+ еженошно запускается codechecker

http://root.cern.ch/root/nightly/codecheck/codecheck.html

> Вот, например, полезный совет оттуда -- использование out в функциях

Применительно к C++ это становится очень плохим советом

b=b*2 - ((a==b)?(b+1):b*(-1))

так и только так

В плюсах использовать goto вообще не надо. Есть риск, например, получить видимую в скопе переменную, которая никак не была инициализирована.

b=b*2 - ((++a,a==b)?(b+1):b*(-1))

Лучше так.

Вам сюда: http://en.wikibooks.org/wiki/C++_Programming/Code_Style

Я пишу в соответствии с ANSI C++ coding style. Документы не читал, но пример есть в любой вменяемой ИДЕ (C::B, NetBeans, Eclipse CDT)

а про codechecker можно поподробнее? интересная штука

Вам совет. Не ищите истину там где её нет. Не существует правильного ответа на ваш вопрос. Обычно приходится руководствоваться одним из двух принципов.

1. Пишем стилем которым привыкли.

2. Пишем стилем который принят там где вы работаете.

З.Ы. А я бы написал

if(a==b)
{
  b++;
}

Хорошая тема для бессмысленных споров.

>И мне пофиг что думают остальные о таком стиле написания.

+1 :)

++b; отработает быстрее, если я правильно помню

А я бы написал:

if( a == b )
{
b++;
}

В общем, тоже пофиг, что думаю о таком стиле остальные.

Перед b++ 4 пробела. =)

>В разговоре со мной один мехматянин как-то давно утверждал, что при ++i операций с памятью происходит на одну меньше, чем при использовании i++

Зависит от конкретных условий, выражений, компилятора. Но я, как раз, в своей практике с обратным сталкивался. Когда ++i требовало лишней операции :)

>++b; отработает быстрее, если я правильно помню

В таком контексте - уже лет 15, как одинаково :)

> Когда ++i требовало лишней операции :)

*ИК* Эт как?

>*ИК* Эт как?

На PDP в машкодах были постинкремент указателя и предекремент. Соответственно *(--i) и *(i++) работали в одну команду, в отличии от *(i--) и *(++i) :)

На x86 - пофиг в любом оптимизирующем компиляторе.

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

> На PDP в машкодах были постинкремент указателя и предекремент.

А, в этом смысле...

У всех по-разному принято. В каждом проекте по-своему. Дело вкуса.

>Как доосилю Страуструпа,

Бесполезное занятие. По теории полезен "Алгоритмы: построение и анализ" и "Приемы объектно-ориентированного проектирования. Паттерны проектирования" от GoF, по обхождению костылей и подпорок С++ - Мейерс "Effective STL" и "Стандарты программирования на С++" от Александреску и Саттера. Строуструп вообще пишет нерелевантную фигню.

> Также интересует этика размещения комментариев к классам и функциям, к действиям.

doxygen

> Была книга.. Кажется, Ален Голуб - "Правила программирования на С++". Там, если не ошибаюсь, было и про стиль кодирование и про комментарии.

+1 имхо классика

лучше писать так, чтобы потом не нужно было разбираться в этом коде :) тогда и на стиль пофиг.
хотя такое удается довольно редко.
я обычно делаю так:
1) в черновом варианте, пока я помню весь код почти наизусть.
if(a==b)
{
b++;
//или b=b+1;
}

2) в финальном варианте, после причесывания обычно
if (a == b)
{
b++;
//или b = b + 1;
}

>Этика написания кода

Перво-наперво нельзя отрицать холокост. Ну и не матерись в комментариях.

stl, boost, posix - snake_case. Я тоже предпочитаю snake_case, но классы часто именую с большой буквы.

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

Нет риска. Компилер заругается.

Решил пользоваться http://techbase.kde.org/Policies/Kdelibs_Coding_Style + разделами «3.1: Spaces» и «8: Commenting» из http://www.kernel.org/doc/Documentation/CodingStyle.

Переписал одну софтинку с учётом этих правил — читабельность поднялась.

Ещё некоторые правила в Google нравятся, например http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#General_Naming_Rules. Но там очень много неприятных мест. Например, все константы предлагают называть kSomeName.

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

>Зависит от конкретных условий, выражений, компилятора. Но я, как раз, в своей практике с обратным сталкивался. Когда ++i требовало лишней операции :)

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