Создатель Linux высказался за увеличение длины строк кода

0. Infostart 05.06.20 16:30 Сейчас в теме
Золотым стандартом для кода ядра Linux считаются 80-символьные строки. Но Торвальдс предлагает увеличить значение до 100 символов.

Перейти к новости

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Bassgood 1048 05.06.20 17:02 Сейчас в теме
Торвальдс считает, что называть переменные именами в пределах 10-15 символов совершенно нормально. Нужно, чтобы имя было понятным.

Интересно а как Торвальдс отнесся бы к вот такому имени объекта "DataCompositionResultSpreadsheetDocumentOutputProcessor"? ;)
Drivingblind; portwein; TreeDogNight; maksa2005; wowik; rusmil; +6 Ответить
2. PerlAmutor 106 05.06.20 18:31 Сейчас в теме
(1) Его продукт - его правила. У 1С свои стандарты, свои правила - https://its.1c.ru/db/v8std/content/456/hdoc

120 символов в строку - норма. Линусу совсем немного осталось до принятия неизбежного.

Кстати давно заметил, что разработчики Java тоже обожают длиннющие названия классов.
5. CheBurator 3426 05.06.20 23:27 Сейчас в теме
(2)
Кстати давно заметил, что разработчики Java тоже обожают длиннющие названия классов.

потому что они нихрена не поймут в своих простынях.
должно быть как в 1С - открыл экран, глянул мельком по одним наименованиям переменных функцйи-процедур уже понятно что и зачем...
а не исследовать тонны двухсимвольных переменных
Hatson; portwein; TreeDogNight; +3 Ответить
13. awk 718 07.06.20 08:34 Сейчас в теме
(5)Что-то мне кажется, что на яве вы не пишете. По вашему посту вы скорее пишете на клюшках или плюсах.
17. Darklight 22 08.06.20 13:21 Сейчас в теме
(2) Да 120 символов в строке - это хорошая норма. Особенно если использовать ультраширокоформатные мониторы - даже на боковую панель места останется. И даже 120 символов - не предел (если это необходимо, а не просто приступ глупости и самомнения) - строки такие возникают не часто (в основном из-за длинных типов) - и в этих случаях очень спасает продвинутая мышка с отдельной боковой прокруткой!
Главное, чтобы главная суть кода была слева, а не справа, а вот, типы - это как раз всторостепенная информация и их правильно размещать справа (а описание определений и логики - слева) , или вообще применять выведение типов и не указывать вовсе. Вот тут Си подобные языки имеют недостаток - у них типы обязаны размещаться слева - и когда они длинные - код активно сезжает вправо даже без учета серий отступов - но это уже недостатки дизайна языка!

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

А в остальных случаях длинные имена переменных - это скорее просто проблема дизайна типов и функций - слишком универсальные комплексные типы порождают сложные имена для своих переменных, призванные пояснить эту универсальность. Сюда же можно отнести и аналогичную проблему функций, содержащих эти переменные - слишком комплексные функции, обрабатывают слишком разнородную информацию - от того и нужно поддерживать содержательные имена для этой информации. Более короткие функции - уже сами по себе (в т.ч. в своём имени и полном пути расположения) сосредоточены на узкой типизации функциональности - и им не нужны длинные имена переменным - т.к. внутри и так ясно что происходит и что обрабатывается!
4. starik-2005 2196 05.06.20 21:44 Сейчас в теме
(1) имя переменной и имя класса - вещи немного разные. Писать что-то типа:
myDataCompositionResultSpreadsheetDocumentOutputProcessor = new DataCompositionResultSpreadsheetDocumentOutputProcessor()
ИМХО не очень.
Bassgood; terrorion; +2 Ответить
6. CheBurator 3426 05.06.20 23:28 Сейчас в теме
(4)
myDataCompositionResultSpreadsheetDocumentOutputProcessor = new DataCompositionResultSpreadsheetDocumentOutputProcessor()


myDCRSDOP = new DCRSDOP() - намного лучше!
14. awk 718 07.06.20 08:38 Сейчас в теме
(6)
Код
processor = new DataCompositionResultSpreadsheetDocumentOutputProcessor()
Показать полностью

Ваш код, не в IDE, набор букв.
user774630; starik-2005; +2 Ответить
18. Darklight 22 08.06.20 14:10 Сейчас в теме
(6)ПроцессорВывода = ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент();
Что Вы тут паритесь, обычной такой короткой записи вполне достаточно - судя из контекста. Не надо называть переменную именем типа - это само по себе - дурной тон.
В контексте существования имени этой переменной такого короткого имени вполне достаточно (учитывая что рядом могут другие процессоры... в переменных).

А вот имя типа тут действительно - слишком длинное - оно могло бы быть допустиммым во внутреннем (скрытом) алгоритме - но не во внешнем API
Тут архитектурно просто сама логика вывода результата компоновки должна была быть иной
Должен был быть один процессор вывода типа "ПроцессорВывода" в пространстве имён "СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных", причём он вполне себе может быть статическми - тут нет смысла создавать экземпляр объекта данного типа)

Использовать (СистемаКомпоновкиДанных, СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных)
{

       //Предшествующий код получения результата компоновки

       ПроцессорВывода.Вывести(РезультатКомпоновки, ТабличныйДокументРезультат);

}



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

Просто 1С ещё не доросла до уровня программирования конца XX века :-(

А можно было бы ещё короче в ещё более сишном виде

ТабличныйДокументРезультат << РезультатКомпоновки;


здесь выбором нужного процессора будет управлять класс объекта "РезультатКомпоновки", зачем этим заниматься программисту - вообще не ясно - а если нужно можно и так

ТабличныйДокументРезультат << ПроцессораВыводаВТабличныйДокумент(РезультатКомпоновки); 


Ту идёт приведение типа "СистемаКомпоновкиДанных.РезультатКомпоновки" в тип "СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных.ПроцессорВывода", приводящий просто к созданию экземпляра процессора вывода и его инициализацией результатом компоновки; и последующее направление вывода в поток табличного документа - приёмника - путём вызова соотвествующего перегруженного оператора напраления в поток из пространства "СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных"


И замечу, ни в одном примере я не создавал переменную процессора вывода - но если нужно было работать с экземпляром объекта - я бы сделал так

Использовать (Новый СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных.ПроцессорВыводаВТабличныйДокумент())
{
      УстановитьИсточник(РезультатКомпоновки);


     //Какой-то ещё код

      Вывести(ТабличныйДокументРезультат );

}
Показать


И у меня опять нет длинных имён переменных - и всё понятно над чем идёт работат даже с длинным именем типа

И это возможно почти во всех современных императивных языках программирования.....



З.Ы.
Ну а вообще - длинные имена некоторых типов в 1С это следствие отсутствия иерархии пространств имён - вообще можно сказать не пространств имён - тем более нет их встроенной библиотеки - всё в одной куче - в 1С 7 - это было ещё приемлемо - но в 1С 8 даже встроенная библиотека выросла уже до очень крупных размеров (не говоря уже о том, что творится в таких конфигурациях как ERP - где тоже было бы неплохо более детально разбить код и типы по отдельным иерархическим подгруппам). И вот всё это содержимое необходимо размещать в едином пространстве имён - чтобы имена не пресекались и оставались понятными - вот они и растут в длину...
3. nvv1970 05.06.20 20:25 Сейчас в теме
7. DitriX 1824 06.06.20 00:05 Сейчас в теме
все зависит от окружения, если у вас все разрабы сидят за ноутами, то да 100-120 норм, у нас все сидят за большими мониторами и мы ставим лимит в 150, и все отлично, главное чтобы удобно было работать всем участникам процесса. ИМХО
8. milanse 35 06.06.20 01:14 Сейчас в теме
(7) у нас тоже все сидели за мониторами, а теперь раз , и бук 15' вместо 27 монитора и кухонный стол вместо удобного офисного стола и кресла )
11. ipoloskov 122 06.06.20 12:52 Сейчас в теме
(8) я офисный монитор притащил домой
12. milanse 35 06.06.20 12:56 Сейчас в теме
(11) полноценного рабочего места нет, некуда ставить.
9. PerlAmutor 106 06.06.20 06:27 Сейчас в теме
А вообще заголовок провокационный получился на главной странице =)
Прикрепленные файлы:
Somebody1; Bassgood; user774630; DoctorRoza; ab_initio; Serega-artem; maksa2005; starik-2005; awk; TreeDogNight; ipoloskov; Senator_I; +12 Ответить
10. Senator_I 13 06.06.20 11:41 Сейчас в теме
(9) Тоже угорнул, дескать, некоторая недосказанность осталась. )))
15. portwein 08.06.20 07:12 Сейчас в теме
(13)
Что-то мне кажется, что на яве вы не пишете

Получается что и создатели Spring-а на Java не пишут - там если имя класса меньше 20 символов, то "можно условно считать это браком")
16. awk 718 08.06.20 08:21 Сейчас в теме
(15)
Получается что и создатели Spring-а на Java не пишут - там если имя класса меньше 20 символов, то "можно условно считать это браком")


Сами придумали и сами опровергли. Я такого не писал. Это называется - софизм.
Оставьте свое сообщение
Вопросы с вознаграждением