Создатель Linux высказался за увеличение длины строк кода
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Торвальдс считает, что называть переменные именами в пределах 10-15 символов совершенно нормально. Нужно, чтобы имя было понятным.
Интересно а как Торвальдс отнесся бы к вот такому имени объекта "DataCompositionResultSpreadsheetDocumentOutputProcessor"? ;)
(2)
потому что они нихрена не поймут в своих простынях.
должно быть как в 1С - открыл экран, глянул мельком по одним наименованиям переменных функцйи-процедур уже понятно что и зачем...
а не исследовать тонны двухсимвольных переменных
Кстати давно заметил, что разработчики Java тоже обожают длиннющие названия классов.
потому что они нихрена не поймут в своих простынях.
должно быть как в 1С - открыл экран, глянул мельком по одним наименованиям переменных функцйи-процедур уже понятно что и зачем...
а не исследовать тонны двухсимвольных переменных
(2) Да 120 символов в строке - это хорошая норма. Особенно если использовать ультраширокоформатные мониторы - даже на боковую панель места останется. И даже 120 символов - не предел (если это необходимо, а не просто приступ глупости и самомнения) - строки такие возникают не часто (в основном из-за длинных типов) - и в этих случаях очень спасает продвинутая мышка с отдельной боковой прокруткой!
Главное, чтобы главная суть кода была слева, а не справа, а вот, типы - это как раз всторостепенная информация и их правильно размещать справа (а описание определений и логики - слева) , или вообще применять выведение типов и не указывать вовсе. Вот тут Си подобные языки имеют недостаток - у них типы обязаны размещаться слева - и когда они длинные - код активно сезжает вправо даже без учета серий отступов - но это уже недостатки дизайна языка!
А насчёт длинных имён - тут не стоит увлекаться - если длинное имя типа (вернее полный путь к типу, со всеми вложенными пространствами имён и типами-классами-владельцами) это просто неизбежность (и есть способы сокращения обрезания к длинным путям), то длинные имена переменных - это не меньшее зло, чем короткие. Но на практике с длинными переменным сталкиваешься очень редко (с очень длинными - вообще не сталкивался); и если придерживаться правила не включать составные части типа в имя переменной - то длинные имена и не возникают.
А в остальных случаях длинные имена переменных - это скорее просто проблема дизайна типов и функций - слишком универсальные комплексные типы порождают сложные имена для своих переменных, призванные пояснить эту универсальность. Сюда же можно отнести и аналогичную проблему функций, содержащих эти переменные - слишком комплексные функции, обрабатывают слишком разнородную информацию - от того и нужно поддерживать содержательные имена для этой информации. Более короткие функции - уже сами по себе (в т.ч. в своём имени и полном пути расположения) сосредоточены на узкой типизации функциональности - и им не нужны длинные имена переменным - т.к. внутри и так ясно что происходит и что обрабатывается!
Главное, чтобы главная суть кода была слева, а не справа, а вот, типы - это как раз всторостепенная информация и их правильно размещать справа (а описание определений и логики - слева) , или вообще применять выведение типов и не указывать вовсе. Вот тут Си подобные языки имеют недостаток - у них типы обязаны размещаться слева - и когда они длинные - код активно сезжает вправо даже без учета серий отступов - но это уже недостатки дизайна языка!
А насчёт длинных имён - тут не стоит увлекаться - если длинное имя типа (вернее полный путь к типу, со всеми вложенными пространствами имён и типами-классами-владельцами) это просто неизбежность (и есть способы сокращения обрезания к длинным путям), то длинные имена переменных - это не меньшее зло, чем короткие. Но на практике с длинными переменным сталкиваешься очень редко (с очень длинными - вообще не сталкивался); и если придерживаться правила не включать составные части типа в имя переменной - то длинные имена и не возникают.
А в остальных случаях длинные имена переменных - это скорее просто проблема дизайна типов и функций - слишком универсальные комплексные типы порождают сложные имена для своих переменных, призванные пояснить эту универсальность. Сюда же можно отнести и аналогичную проблему функций, содержащих эти переменные - слишком комплексные функции, обрабатывают слишком разнородную информацию - от того и нужно поддерживать содержательные имена для этой информации. Более короткие функции - уже сами по себе (в т.ч. в своём имени и полном пути расположения) сосредоточены на узкой типизации функциональности - и им не нужны длинные имена переменным - т.к. внутри и так ясно что происходит и что обрабатывается!
(6)ПроцессорВывода = ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент();
Что Вы тут паритесь, обычной такой короткой записи вполне достаточно - судя из контекста. Не надо называть переменную именем типа - это само по себе - дурной тон.
В контексте существования имени этой переменной такого короткого имени вполне достаточно (учитывая что рядом могут другие процессоры... в переменных).
А вот имя типа тут действительно - слишком длинное - оно могло бы быть допустиммым во внутреннем (скрытом) алгоритме - но не во внешнем API
Тут архитектурно просто сама логика вывода результата компоновки должна была быть иной
Должен был быть один процессор вывода типа "ПроцессорВывода" в пространстве имён "СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных", причём он вполне себе может быть статическми - тут нет смысла создавать экземпляр объекта данного типа)
Причём "ПроцессорВывода" тут общий класс (причём ещё воpможно примеряющий классы-расширения(хелперы) для расширения своего внешнего API), а вот функция "Вывести" возможно имеет перегрузки (ну или ветвление внутри) - где нужная логика реализации вывода определяется исходно переданными типами объектов- аргументов).
Вот когда нужная логика выбрана - вот тогда уже создаётся конкретный экземпляр процессора вывода - осуществляет вывод - и там имя типа такого процессора уже может иметь произвольную длину - это всё равно будет скрыто для внешнего программиста. А для внутреннего и по контексту этой реализации всё будет понятно.
Просто 1С ещё не доросла до уровня программирования конца XX века :-(
А можно было бы ещё короче в ещё более сишном виде
здесь выбором нужного процессора будет управлять класс объекта "РезультатКомпоновки", зачем этим заниматься программисту - вообще не ясно - а если нужно можно и так
Ту идёт приведение типа "СистемаКомпоновкиДанных.РезультатКомпоновки" в тип "СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных.ПроцессорВывода", приводящий просто к созданию экземпляра процессора вывода и его инициализацией результатом компоновки; и последующее направление вывода в поток табличного документа - приёмника - путём вызова соотвествующего перегруженного оператора напраления в поток из пространства "СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных"
И замечу, ни в одном примере я не создавал переменную процессора вывода - но если нужно было работать с экземпляром объекта - я бы сделал так
И у меня опять нет длинных имён переменных - и всё понятно над чем идёт работат даже с длинным именем типа
И это возможно почти во всех современных императивных языках программирования.....
З.Ы.
Ну а вообще - длинные имена некоторых типов в 1С это следствие отсутствия иерархии пространств имён - вообще можно сказать не пространств имён - тем более нет их встроенной библиотеки - всё в одной куче - в 1С 7 - это было ещё приемлемо - но в 1С 8 даже встроенная библиотека выросла уже до очень крупных размеров (не говоря уже о том, что творится в таких конфигурациях как ERP - где тоже было бы неплохо более детально разбить код и типы по отдельным иерархическим подгруппам). И вот всё это содержимое необходимо размещать в едином пространстве имён - чтобы имена не пресекались и оставались понятными - вот они и растут в длину...
Что Вы тут паритесь, обычной такой короткой записи вполне достаточно - судя из контекста. Не надо называть переменную именем типа - это само по себе - дурной тон.
В контексте существования имени этой переменной такого короткого имени вполне достаточно (учитывая что рядом могут другие процессоры... в переменных).
А вот имя типа тут действительно - слишком длинное - оно могло бы быть допустиммым во внутреннем (скрытом) алгоритме - но не во внешнем API
Тут архитектурно просто сама логика вывода результата компоновки должна была быть иной
Должен был быть один процессор вывода типа "ПроцессорВывода" в пространстве имён "СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных", причём он вполне себе может быть статическми - тут нет смысла создавать экземпляр объекта данного типа)
Использовать (СистемаКомпоновкиДанных, СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных)
{
//Предшествующий код получения результата компоновки
ПроцессорВывода.Вывести(РезультатКомпоновки, ТабличныйДокументРезультат);
}Причём "ПроцессорВывода" тут общий класс (причём ещё воpможно примеряющий классы-расширения(хелперы) для расширения своего внешнего API), а вот функция "Вывести" возможно имеет перегрузки (ну или ветвление внутри) - где нужная логика реализации вывода определяется исходно переданными типами объектов- аргументов).
Вот когда нужная логика выбрана - вот тогда уже создаётся конкретный экземпляр процессора вывода - осуществляет вывод - и там имя типа такого процессора уже может иметь произвольную длину - это всё равно будет скрыто для внешнего программиста. А для внутреннего и по контексту этой реализации всё будет понятно.
Просто 1С ещё не доросла до уровня программирования конца XX века :-(
А можно было бы ещё короче в ещё более сишном виде
ТабличныйДокументРезультат << РезультатКомпоновки;
здесь выбором нужного процессора будет управлять класс объекта "РезультатКомпоновки", зачем этим заниматься программисту - вообще не ясно - а если нужно можно и так
ТабличныйДокументРезультат << ПроцессораВыводаВТабличныйДокумент(РезультатКомпоновки);
Ту идёт приведение типа "СистемаКомпоновкиДанных.РезультатКомпоновки" в тип "СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных.ПроцессорВывода", приводящий просто к созданию экземпляра процессора вывода и его инициализацией результатом компоновки; и последующее направление вывода в поток табличного документа - приёмника - путём вызова соотвествующего перегруженного оператора напраления в поток из пространства "СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных"
И замечу, ни в одном примере я не создавал переменную процессора вывода - но если нужно было работать с экземпляром объекта - я бы сделал так
Использовать (Новый СистемаКомпоновкиДанных.ПроцессорыОбработкиДанных.ПроцессорВыводаВТабличныйДокумент())
{
УстановитьИсточник(РезультатКомпоновки);
//Какой-то ещё код
Вывести(ТабличныйДокументРезультат );
}
ПоказатьИ у меня опять нет длинных имён переменных - и всё понятно над чем идёт работат даже с длинным именем типа
И это возможно почти во всех современных императивных языках программирования.....
З.Ы.
Ну а вообще - длинные имена некоторых типов в 1С это следствие отсутствия иерархии пространств имён - вообще можно сказать не пространств имён - тем более нет их встроенной библиотеки - всё в одной куче - в 1С 7 - это было ещё приемлемо - но в 1С 8 даже встроенная библиотека выросла уже до очень крупных размеров (не говоря уже о том, что творится в таких конфигурациях как ERP - где тоже было бы неплохо более детально разбить код и типы по отдельным иерархическим подгруппам). И вот всё это содержимое необходимо размещать в едином пространстве имён - чтобы имена не пресекались и оставались понятными - вот они и растут в длину...
все зависит от окружения, если у вас все разрабы сидят за ноутами, то да 100-120 норм, у нас все сидят за большими мониторами и мы ставим лимит в 150, и все отлично, главное чтобы удобно было работать всем участникам процесса. ИМХО
