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

★★★★★

Последнее исправление: crutch_master (всего исправлений: 3)

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

Aber ★★★★★
()

// --- Назначение функции
//
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
()
Ответ на: комментарий от unittests

А представь, если у тебя на страницу этих перегрузок в первом варианте. Какой смысл размазывать это всё в сопли, кроме религии?

crutch_master ★★★★★
() автор топика

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

no-such-file ★★★★★
()

Лично я терпеть не могу подобный квадратно-гнездовой код, неудобно писать, неприятно поддерживать и развивать.

I-Love-Microsoft ★★★★★
()

В топку, второй вариант всё равно читаемей из-за коротких строк.

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

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

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

Мне вот нравится один тип девушек, моему другу совсем другие. По твоему нужно навязывать свои вкусы другим людям?

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

а коммит получается на 100500 строк - сиди гадай, что из этого реальная правка, а что просто для красоты.

Ну да, так мусора в диффах будет много.

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

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

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

pihter ★★★★★
()

учитывая схожесть вызовов - первый вариант предпочтительней: сразу видно отличия

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

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

unittests
()

В какой-то мере мне импонирует стиль написания кода в Oberon.

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

не вижу никаких проблем, если не использовать консоль с diff. используй нормальные средства для версионирования (ГУЙные)

bvn13 ★★★★★
()
Ответ на: комментарий от 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
()
Ответ на: комментарий от unittests

Ну стало и что? Видно же, что просто всё сдвинули, да и в комментарии это можно отметить или вообще отдельным коммитом форматирование. Такая себе проблема.

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

Ты сейчас говоришь так:
Идет игра в футбол, ты один из футболистов.
Зачем бить в дальние ворота противника, свои же ближе.
Давай те бить в свои ворота :)

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

Ты не последователен. Начал за вкусовщину, закончил за общепринятые правила.

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

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

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

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

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

crutch_master ★★★★★
() автор топика

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

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

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

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

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

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

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

Тогда поменялся бы fn и смотреть следует его.

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

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

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

slackwarrior ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

Ну а что делать, если дефолтных параметров в язык не завезли.

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

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

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

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

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

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

unittests
()

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

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

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

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

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

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

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

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