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

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

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

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

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

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

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

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

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

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


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

Ваш код, не в IDE, набор букв.
user774630; starik-2005; +2 Ответить
18. Darklight 29 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 2055 06.06.20 00:05 Сейчас в теме
все зависит от окружения, если у вас все разрабы сидят за ноутами, то да 100-120 норм, у нас все сидят за большими мониторами и мы ставим лимит в 150, и все отлично, главное чтобы удобно было работать всем участникам процесса. ИМХО
8. milanse 36 06.06.20 01:14 Сейчас в теме
(7) у нас тоже все сидели за мониторами, а теперь раз , и бук 15' вместо 27 монитора и кухонный стол вместо удобного офисного стола и кресла )
11. ipoloskov 158 06.06.20 12:52 Сейчас в теме
(8) я офисный монитор притащил домой
12. milanse 36 06.06.20 12:56 Сейчас в теме
(11) полноценного рабочего места нет, некуда ставить.
9. PerlAmutor 129 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 17 06.06.20 11:41 Сейчас в теме
(9) Тоже угорнул, дескать, некоторая недосказанность осталась. )))
15. portwein 08.06.20 07:12 Сейчас в теме
(13)
Что-то мне кажется, что на яве вы не пишете

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


Сами придумали и сами опровергли. Я такого не писал. Это называется - софизм.
Оставьте свое сообщение
Вакансии
1С разработчик
Москва
зарплата от 150 000 руб. до 200 000 руб.
Полный день

Руководитель группы разработки
Краснознаменск (Московская обл.)
зарплата от 180 000 руб. до 300 000 руб.
Полный день

Инженер 1С
Ессентуки
зарплата от 120 000 руб. до 144 000 руб.
Полный день

Программист 1С
Краснознаменск (Московская обл.)
зарплата от 150 000 руб. до 250 000 руб.
Полный день

Специалист техподдержки
Краснознаменск (Московская обл.)
зарплата от 50 000 руб. до 100 000 руб.
Полный день