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

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

как мерял читабельность? теми-же глазами, которыми переписывал?

Переписывал руками, мерил глазами :). Может, мне ещё двойное слепое тестирование на большой выборке провести?

Я же говорил, что пока что для себя пишу.

> Может, мне ещё двойное слепое тестирование на большой выборке провести?

Обязательно рандомизированное и с плацебо-контролем! 8))

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

doxygen

Я не совсем это имел в виду. Но doxygen мы в любом случае стоит использовать — там, где много матана, с лейтехом всё должно лучше пониматься.

Но doxygen мы в любом случае стоит использовать

O_O

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

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

А можно и так:

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

Чё уж там мелочиться...

например: OpenBSD Kernel source file style guide, а вообще, всё зависит от договорённости.

кстати, Use indent(1), Luke!

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

Потому что так веками повелось http://java.sun.com/docs/codeconv/

А можно начать и с:
http://astyle.sourceforge.net/astyle.html

:))

>Но doxygen мы в любом случае стоит использовать

Стоит, и латех ни при чём. doxygen в контексте этой темя - это стандарт на оформление комментов и контрольный список для их содержимого. Такие комментарии имеет смысл писать даже если дока не будет генерироваться.

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

1. (уже ответили)

2. выход из вложенного цикла требует goto

posix каким образом к C++ относится?

>posix каким образом к C++ относится?

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

>выход из вложенного цикла требует goto

На эту тему была дискуссия: http://www.linux.org.ru/view-message.jsp?msgid=3520569 Вкратце: я предлагал использовать goto для выхода из вложенных циклов, но меня переубедили.

> все переменные — с маленькой буквы;

+1

> все константы — только большими буквами;

+1

> имена классов и типов — с большой буквы;

+1

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

если в смысле "не использовать _ первым символом" - то +1. если "не использовать _ при именовании переменных/методов/етц" - то -1.

еще добавлю - методы классов и функций с маленькой буквы, вроде getThisVar() или syncThisObject() или transform_array().

На эту тему была дискуссия: www.linux.org.ru/view-message.jsp?msgid=3520569 Вкратце: я предлагал использовать goto для выхода из вложенных циклов, но меня переубедили.

Ни разу не убедительно — goto в твоем бенче показало лучшее время, и вероятно и будет показывать, так как разработчики компилятора воспринимают этот случай как стандартный.

Предолжение Мигеля было интересно (особенно в случае концептуальности именно пути), однако:

1. его надо написать на шаблонах, чтобы оно не тормозило

2. вероятность его тормозов все равно >0

3. оно не аргумент для запрета goto

  while(i...) {
    while(j...) {
      switch(...) {
        case 'a' : goto apple;
        case 'b' : goto banana;
  } } }
  std::cout << "sorry";
  // half a page code here
  goto end;
apple: 
  std::cout << "apple found with " << f(i,j);
  // half a page code here
  goto end;
banana:
  std::cout << "banana found with " << g(i,j);
  // half a page code here
  goto end;
end:

понятно, что все по меткам можно запихать внутрь цикла, но это — нечитабельное тупое поклонение авторитету

З.Ы. правильное решение — реализация «статических» исключений средствами метапрограммирования

я в той теме промолчал только потому, что мне показалось, что все ясна победа goto

чтобы реализовать мой пример через return, тебе придется придумать никому не нужный enum BlaBlaBla {apple, banana}, возвращать его из функции, а потом делать по нему свитч, да еще и не забыть добавить в свитч один из вариантов, когда ты его добавишь в цикл!

кроме опасности, оно еще и тормозит -- в цикле ты знаешь куда надо прыгать, но нет -- мы будет это вспоминать в свиче. может жцц и соптимизирует это, но нафига?

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

>я в той теме промолчал только потому, что мне показалось, что все ясна победа goto

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

>тебе придется придумать никому не нужный enum BlaBlaBla {apple, banana}

Он нужный, ибо:

1. самодокументируемость: сразу видно какие вообще фрукты бывают.

2. компиляторы умеют предупреждать, когда в switch перечислены не все элементы enum.

B в первую очередь в твоём коде выкинуть в функции надо "// half a page code here"

Что скажешь о книге Лафоре «Объектно-ориентированное программирование в C++»? Мне тоже Страуструп несколько не нравится — как-то бессвязно всё. Больше похоже на справочник, а не на руководство.

> B в первую очередь в твоём коде выкинуть в функции надо "// half a page code here"

// this page of code is intentionally left blank

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

Вообще говоря, это все должен решать компилятор. И уж тем более это решать компилятору, если использование идет в контексте if (a==b) b++;

BTW, http://en.wikipedia.org/wiki/Indent_style

1TBS хорош.

>Что скажешь о книге Лафоре «Объектно-ориентированное программирование в C++»

Не читал Лафоре. Попробуй Мейерса почитать, только учти что его Effective C++ и More Effective C++ уже немного устарели, Effective STL посвежее будет, но там уклон в STL. Саттер еще в той же канве пишет. Если нужен ООП то хорошо почитать "Приемы объектно-ориентированного проектирования. Паттерны проектирования" от GoF. Это все короткие книжки страниц по 300-400. Более толстые технические книги это или энциклопедии/альманахи или непонятные аутпуты людей не могущих излагать мысли.

> Более толстые технические книги это или энциклопедии/альманахи или непонятные аутпуты людей не могущих излагать мысли.

Угу, канонический талмуд Страус-трупа - классика жанра. Ещё в этом ключе можно "порекомендовать" Programming Perl великого лингвиста Ларри. Обязательно нужно прочесть, чтобы навсегда избавится от желания заюзать перл.

Вообще сказать, мне язык для вполне конкретных целей нужен — для моделирования мерзлоты. От лёгкого (известна зависимость f(x,z,t), надо найди несколько её точек на заданном диапазоне с заданной допустимой ошибкой для t=0) до тяжёлого (двухмерное пространство 3000x3000 ячеек, в нём есть известные источники тепла + есть теплопоток из недр и с поверхности, задана изначальная увлажнённость и свойства грунта, состав влаги, высчитать как оно будет изменяться во времени... там мильён зависимостей — идёт миграция, фазовые переходы, изменение размеров ячеек (пучение), образование прослоев льда и т.д., это очень диффуры и прочего, нынешняя модель на C# очень медленна при том, что там всего 300x300 ячеек).

И из-за полного отсутствия опыта я даже и не знаю, какая парадигма программирования в данном удобнее/эффективнее. Так как по сути не владею ни одной. Вот ты бы что думаешь?

>И из-за полного отсутствия опыта я даже и не знаю, какая парадигма программирования в данном удобнее/эффективнее

Ну вообще обычно в матлабе прототипируют такие вещи, а потом переносят на Си.

Вот пример программы — http://pastebin.mozilla-russia.org/102300. Индусский код как он есть, видимо. Учусь пока. Не знаю, какую я тут парадигму использовал. Классифицируешь?

Задача такая. Известна формула T(x,z). Также известно, что функция в каждой плоскости представляет собой кривую (т.е. не бывает такого, чтобы она имела решение на площади). Найти в квадрате со стороной 250, идущем от нуля, несколько точек таких, что T(x,z)==константе (T_NEEDED). Для каждой точки есть допустимая ошибка: |T(x0,z0)-T_NEEDED|<=MAX_MISTAKE.

Сделал так: иду по Z от 0 до 250 с постоянным шагом. Для каждого z иду по X от 0 до 250 с постоянным шагом и смотрю, пока не пересеку функцию. Я её пересёк в том случае, когда в начале шага значение T(x,z) было больше (меньше) нужного, а в конце стало меньше (больше) нужного. Как только мы пересекли функцию, разбиваем шажок пополам и выбираем половинку с меньшей ошибкой до тех пор, пока не добъёмся допустимой ошибки. Все значения заносим в массив. В конце выводим содержание массива на стандартный вывод.

Как тут вообще можно бы было использовать ООП? А обобщённое программирование?

А как (не в обычном массиве же!) тут лучше хранить данные, кстати (из соображений производительности)?

P.S.: Конкретно в этом случае функция такая, что для каждого z существует единственный x, так что шаг по X я сделал равным 250. Но это только частный случай. Результат исполнения: http://pic.ipicture.ru/uploads/091024/32UyPcap5b.png (там несколько кривых, для разных T_NEEDED).

> Ну вообще обычно в матлабе прототипируют такие вещи, а потом переносят на Си.

Да, мне уже говорили. Но если оно и подойдёт для более простых случаев (которые я так бы и делал, если бы опыт не нужен был), то для тяжёлой модели, о которой я говорил — нифига, она слишком комплексная.

>Задача такая. Известна формула T(x,z). Также известно, что функция в каждой плоскости представляет собой кривую (т.е. не бывает такого, чтобы она имела решение на площади). Найти в квадрате со стороной 250, идущем от нуля, несколько точек таких, что T(x,z)==константе (T_NEEDED). Для каждой точки есть допустимая ошибка: |T(x0,z0)-T_NEEDED|<=MAX_MISTAKE

Метод градиентного спуска изобретаешь?

>Как тут вообще можно бы было использовать ООП?

Чего ты с помошью него хочешь достичь?

>А обобщённое программирование?

Если кода слишком много и он однотипный, то можно попытаться написать eDSL на exprеssion-темплейтах. Но это *немного* сложно.

>А как (не в обычном массиве же!) тут лучше хранить данные, кстати (из соображений производительности)?

Чем тебя массив не устраивает? O(1) к любому элементу, совместим с чистым Си, элементы хранятся в памяти рядом отчего caсhe-miss происходит редко, накладные расходы на каждый элемент - ноль байт. Ресайзить только надо с запасом.

> Метод градиентного спуска изобретаешь?

OH SHI--

> Чего ты с помошью него хочешь достичь?

Большего удобства написания. Или лучшей читабельности.

> O(1) к любому элементу

Вопрос снят.

Так что, не скажешь, какая парадигма использована в этой програмке? :S

> Метод градиентного спуска изобретаешь?

И метод золотого сечения заодно. Ну не было у нас ни теории алгоритмов, ни программирования, ничего...

>> O(1) к любому элементу

>Вопрос снят.

Что тебя не устраивает?

>Так что, не скажешь, какая парадигма использована в этой програмке?

Нормальный тащемта код, если не обращать внимание на то что алгоритм мог быть пооптимальней если зарыться в матан. Зачем там какие-то парадигмы?

> Что тебя не устраивает?

Напротив, всё устраивает. Ошибочно думал, что это у vector O(1) при записи в конец, а при записи в массив порядок выше.

> Нормальный тащемта код, если не обращать внимание на то что алгоритм мог быть пооптимальней если зарыться в матан.

Помимо того факта, что стоило бы использовать золотое сечение, а не деление пополам, есть что-нибудь важное?

>Ошибочно думал, что это у vector O(1) при записи в конец, а при записи в массив порядок выше.

Там у тебя треды, а два треда одновременно не могут делать push_back в конец вектора, надо мютекс захватывать.

>> Нормальный тащемта код, если не обращать внимание на то что алгоритм мог быть пооптимальней если зарыться в матан.

>Помимо того факта, что стоило бы использовать золотое сечение, а не деление пополам, есть что-нибудь важное?

Нет.

UPD: Делать for по double-переменной я бы не стал. Изучал черную магию с флоатами я давно, но насколько я помню умножение для флоатов это более предпочтительная операция чем сложение, так что ИМХО лучше делать цикл по int и конвертировать его в double + умножать на масштабный коэффициент.

Ясно. Тогда просто использую for, аналогичный тому, что в main'е.

Чем посоветуешь предварить чтение книги Александреску и Саттера «C++ Coding Standards : 101 Rules, Guidelines, and Best Practices»? Хотелось бы пошаговое объяснение всего, кроме того, что устарело и почти не используется.

BTW, а нужны ли в подобном плюсы вообще? Может, лучше брать Белую Библию, пока не поздно?

http://www.ozon.ru/context/detail/id/1273565/ по отзывам в рунете нравится...

Да, и такой вопрос — в том коде по правилам хорошего тона надо занести внутрь double T те константы, которые нужны только в ней?

> Хотелось бы пошаговое объяснение всего, кроме того, что устарело и почти не используется.

ИРЛ "устарело" используется почти везде.

>Чем посоветуешь предварить чтение книги Александреску и Саттера «C++ Coding Standards : 101 Rules, Guidelines, and Best Practices»?

GoF (паттерны проектирования) наверное - они по ходу книги пишут текстовой редактор применяя ООП. Может дать понимание как ООП вообще практически используется если пытаться его использовать осмысленно. Как устроена плавающая точка написано во втором томе Кнута, но там очень много матана и асма.

>а нужны ли в подобном плюсы вообще?

По идее эксперт может их использовать для того чтобы создать eDSL для математики. Но Луговский это не осилил, например.

> UPD: Делать for по double-переменной я бы не стал.

Лорчую. Любое плавающе как счетчик цикла - косяк.

>в том коде по правилам хорошего тона надо занести внутрь double T те константы, которые нужны только в ней?

В Unreal-е константы с плавающей запятой вообще определяются через #define.

Ну... то, что устарело и лучше бы не использовалось.

> Как тут вообще можно бы было использовать ООП? А обобщённое программирование?

Да никак, это все тебе нафик не нужно. Пиши безо всяких объектов. У тебя задача - чисто вычислительная. Плюсы тебе просто не нужны - это оверкилл.

> А как (не в обычном массиве же!)

Почему не в массиве? У тебя много и часто меняется количество данных по ходу работы?

В Unreal-е константы с плавающей запятой вообще определяются через #define.

Да, часть констант так и буду делать, наверное. Шустрее же.

Касательно выбора языка... надо будет мне переписать это же на чистом С и на пайтоне (поискав замену OpenMP) и сравнить производительность.

>> В Unreal-е константы с плавающей запятой вообще определяются через #define.

>Да, часть констант так и буду делать, наверное. Шустрее же.

Для начала амовые листинги сравни. MSVS раньше очень анально реализовывала const double-ы, но сомневаюсь что в новых гыцацах будет разница между const и #define.

вот еще до кучи
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml