LINUX.ORG.RU

Допускаете ли вы такой стиль кода?

 , ,


0

1

Что лучше и правильнее?

public void foo   (Double a)            {fn(0, 0, a,  "foo");   }
public void foo   (Double a, Integer b) {fn(0, b, a,  "foo");   }
public void bar   (Double a)            {fn(a, 0, 0d, "bar");   }
public void bar   (Double a, Integer b) {fn(a, b, 0d, "bar");   }
public void foobar(Double a, Integer b) {fn(a, b, a,  "foobar");}

или

public void foo(Double a) 
{
    fn(0, 0, a, "foo");  
}
public void foo(Double a, Integer b) 
{
    fn(0, b, a,  "foo");
}
public void bar(Double a) 
{
    fn(a, 0, 0d, "bar");
}
public void bar(Double a, Integer b) 
{
    fn(a, b, 0d, "bar");   
}
public void foobar(Double a, Integer b) 
{
    fn(a, b, a,  "foobar");
}


// --- Назначение функции
//
public void foo(
 Double  a
) {
/*

 a                      Назначение переменной

 Notes:                 .

 Links:                 .

*/

 fn(
  0,                                                       // Назначение параметра
  0,
  a,
  "foo"
 );

}                                                          // public void foo(
anonymous ()
Ответ на: комментарий от Aber

в автоформаттере IDE не настроить

Потому, что туда редакторов не завезли:

:set ts=2
:nmap <tab> !ipcolumn -t -s $'\t' -o $'\t'
Чтобы без табов - нужно column заменить. или починить, чтобы только на 2+ пробелов реагировал.

DonkeyHot ★★★★★ ()

Имхо, лучше чтобы все было единообразно по всей кодовой базе.
1 или 2 дело вкуса человека который отвечает за качество кода.
Настроить clang-format на первый или второй форматы.
И на каждый коммит проверять форматирование и не пропускать если формат не соответствует, в особо тяжелых случаях - бить по рукам.

unittests ()

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

no-such-file ★★★★★ ()
Ответ на: комментарий от crutch_master

Смысл в том, что с этим кодом будет работать вся команда,
программирование это командная дисциплина.
Стандарты придуманы не для удобства какого то конкретного индивида.

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

Первый вариант в автоформаттере IDE не настроить - не пригодно в реальной жизни.

Может у тебя просто IDE неправильная? ) имхо, первое читабельнее в разы, стало быть, голосую за первую

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

Как тебе GUI здесь поможет? Это всего лишь обертка над консолью.
Если у тебя сдвинутся скобки на пробел или таб, GUI тебе и выдаст что изменения есть и это сдвиг скобок. было:

public void foo (Double a) {fn(0, 0, a,  "foo");}
стало:
public void foo   (Double a)            {fn(0, 0, a,  "foo");   }
public void foo   (Double a, Integer b) {fn(0, b, a,  "foo");   }

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

Система развивается N лет. Коммитов over 100500. Каждый задействует изменение:

public void foo (Double a) {fn(0, 0, a,  "foo");}
ты хочешь знать почему тип Double а не int/float. Хочешь узнать кто изменял эту функцию. В результате ты должен просмотреть все коммиты линейным поиском за O(n). Вместо того чтобы просмотреть 3 реальных изменения в этом куске кода.

unittests ()

как по мне - второй вариант, а первый не выгоден, т.к. во втором нечему плыть и а второй поплывет при рефакторенге имен или параметров.

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

отдельным коммитом форматирование

Это не всегда возможно.

Такая себе проблема

Мусор в коммитах будет усложнять не только на восприятие диффов, но и, в нетривиальных случаях, конфликты при слиянии. Зачем создавать проблему, если её можно не создавать?

no-such-file ★★★★★ ()
Ответ на: комментарий от crutch_master

если у тебя на страницу этих перегрузок

искусственнопроблемы, искусственнопроблемушки :) Какой смысл решать проблемы, вместо того чтоб их не создавать? Старое доброе чувство меры, не не слышал? «Если функция занимает N-экранов, если перегрузок больше M, если копипаста... --> подумай еще и не делай так»

slackwarrior ★★★★★ ()

Первый вариант не читаем, второй привычен - выбор очевиден. Код должно быть удобно читать, первый вариант этому критерию не соответствует.

Noob_Linux ★★★ ()
Ответ на: комментарий от no-such-file

Мусор в коммитах будет усложнять не только на восприятие диффов, но и, в нетривиальных случаях, конфликты при слиянии. Зачем создавать проблему, если её можно не создавать?

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

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

портянка хреново читается

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

PS: я так пробовал. Сначала кажется, что всё красиво, но со временем эта дрочильня с постоянным двиганьем туда-сюда и разгребанием старых коммитов дико за"бывает.

no-such-file ★★★★★ ()
Ответ на: комментарий от crutch_master

Ты ищешь серебряную пулю, а ее нет.
У обоих представленных тобою вариантов есть свои плюсы и минусы.
Все зависит от других не указанных тобою данных.
Как то:

  • количество разработчиков
  • размер кодовой базы,
  • сколько лет ведется разработка.

Это все равно что спорить о том, что лучше

  • вектор
  • список

Без указания какие ты будешь производить операции, какой объем данных.

unittests ()

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

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

по-моему вопрос из серии

комментировать ли строку типа i=i+1.

Если она очевидна (по-моему она очевидна) то комментировать её не нужно ни при каких обстоятельствах.

Можно конечно говорить что «ёлы-палы, а как же стандарты?!?!» и тд ... (такие люди просто обязаны пить пиво строго в объемах 0.5, 1.0 или 2.0 л и не покупать продукты в упаковках по 950 г)

Но стандарты не обазательно соблюдать всю жизнь

sshestov ()