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

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

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

kemm
()
Ответ на: комментарий от kemm

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

if (a == b)
   ++b;

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

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

Obey-Kun ★★★★★
() автор топика

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

fasol8
()

а если так:

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

этично? :)

jtootf ★★★★★
()

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

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

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

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

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

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

Obey-Kun ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

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

Obey-Kun ★★★★★
() автор топика
Ответ на: комментарий от Obey-Kun

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

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

jtootf ★★★★★
()
Ответ на: комментарий от Obey-Kun

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 ★★★★★
() автор топика

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

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

Love5an
()

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

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

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

ntp
()
Ответ на: комментарий от Love5an

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

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

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

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

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

Obey-Kun ★★★★★
() автор топика
if (a == b)
   b++;
UVV ★★★★★
()

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

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

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

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

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

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

EvgenyVoid
()

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

Legioner ★★★★★
()
Ответ на: комментарий от power

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

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

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

Valeriy_Onuchin ★★
()
Ответ на: комментарий от Obey-Kun

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

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

mannaz
()
Ответ на: комментарий от Obey-Kun

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

Miguel ★★★★★
()
Ответ на: комментарий от Valeriy_Onuchin

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

k0l0b0k ★★
()

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

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

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

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

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

pathfinder ★★★★
()

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

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

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

+1 :)

k0l0b0k ★★
()
Ответ на: комментарий от Obey-Kun

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от VladimirMalyk

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от kemm

>*ИК* Эт как?

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

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

KRoN73 ★★★★★
()

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

golodranez ★★★★
()
Ответ на: комментарий от KRoN73

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

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

kemm
()

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

smh ★★★
()
Ответ на: комментарий от Obey-Kun

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

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

Absurd ★★★
()
Ответ на: комментарий от EvgenyVoid

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

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

dilmah ★★★★★
()

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

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

xydo ★★
()

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

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

legolegs ★★★★★
()
Ответ на: комментарий от Miguel

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

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

legolegs ★★★★★
()

Решил пользоваться 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 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

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

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

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