LINUX.ORG.RU

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


0

0

Где можно почитать про сабж? Как именовать классы, из каких соображений разбивать код на файлы, почему не принято использовать CamelCode, как вообще оформлять код?

Вот как обычно делают?

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

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

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

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

kemm ()
Ответ на: [c++] Этика написания кода от kemm

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

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

if (a == b)
   ++b;

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

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

Obey-Kun ★★★★★ ()

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

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

fasol8 ()

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

Мой вариант:

if(a == b)
    b++;

:)

KRoN73 ★★★★★ ()

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

а если так:

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

этично? :)

jtootf ★★★★★ ()

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

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

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

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

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

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

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

Obey-Kun ★★★★★ ()
Ответ на: [c++] Этика написания кода от KRoN73

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

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

Obey-Kun ★★★★★ ()
Ответ на: [c++] Этика написания кода от Obey-Kun

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

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

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

jtootf ★★★★★ ()
Ответ на: [c++] Этика написания кода от Obey-Kun

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

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;
}

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

Obey-Kun ★★★★★ ()

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

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

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

Love5an ()

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

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

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

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

ntp ()
Ответ на: [c++] Этика написания кода от Love5an

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

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

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

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

  • все переменные — с маленькой буквы;
  • все константы — только большими буквами;
  • имена классов и типов — с большой буквы;
  • вместо подчерков начинать новое слово с большой буквы.
Obey-Kun ★★★★★ ()
Ответ на: [c++] Этика написания кода от ntp

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

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

Obey-Kun ★★★★★ ()

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

if (a == b)
   b++;
UVV ★★★★★ ()

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

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

if (a == b) {
    b++;
}
Скобки - по двум причинам. Первая: чтобы везде было одинаково, каждый if с фигурными скобками, не зависимо от количества операторов в теле. Вторая: если захочется что-то добавить в этот блок, непридется помнить о необходимости добавления скобок. Открывающая скобка на той же строке... Ну открывающая скобка на той же строке - прост привычка. Выношу её на новую строку только в функциях и типах.

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

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

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

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

EvgenyVoid ()

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

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

Legioner ★★★★★ ()
Ответ на: [c++] Этика написания кода от ntp

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

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

power ()
Ответ на: [c++] Этика написания кода от power

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

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

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

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

Valeriy_Onuchin ★★ ()
Ответ на: [c++] Этика написания кода от Obey-Kun

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

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

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

mannaz ()

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

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

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

wfrr ★★☆ ()
Ответ на: [c++] Этика написания кода от Obey-Kun

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

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

Miguel ★★★★★ ()

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

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

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

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

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

if(a==b)
{
  b++;
}
И мне пофиг что думают остальные о таком стиле написания.

pathfinder ★★★ ()

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

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

pathfinder ★★★ ()
Ответ на: [c++] Этика написания кода от pathfinder

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

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

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

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

Ian ★★ ()
Ответ на: [c++] Этика написания кода от Obey-Kun

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

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

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

KRoN73 ★★★★★ ()
Ответ на: [c++] Этика написания кода от VladimirMalyk

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

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

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

KRoN73 ★★★★★ ()
Ответ на: [c++] Этика написания кода от kemm

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

>*ИК* Эт как?

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

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

KRoN73 ★★★★★ ()

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

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

golodranez ★★★★ ()
Ответ на: [c++] Этика написания кода от KRoN73

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

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

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

kemm ()

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

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

smh ★★★ ()
Ответ на: [c++] Этика написания кода от Obey-Kun

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

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

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

Absurd ★★★ ()
Ответ на: [c++] Этика написания кода от Obey-Kun

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

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

doxygen

LamerOk ★★★★★ ()
Ответ на: [c++] Этика написания кода от EvgenyVoid

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

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

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

dilmah ★★★★★ ()

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

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

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

xydo ★★ ()

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

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

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

legolegs ★★★★★ ()
Ответ на: [c++] Этика написания кода от Love5an

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

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

legolegs ★★★★★ ()
Ответ на: [c++] Этика написания кода от Miguel

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

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

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

legolegs ★★★★★ ()

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

Решил пользоваться 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.

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

Obey-Kun ★★★★★ ()
Ответ на: [c++] Этика написания кода от KRoN73

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

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

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

legolegs ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.