LINUX.ORG.RU

Kernel 5.7 и нововведение

 


0

1

C 80 до 100 символов увеличено ограничение на максимальную длину строки в исходных текстах. При этом разработчикам по-прежнему рекомендуется держаться в границах 80 символов в строке, но это теперь не является жёстким лимитом. Кроме того, превышение лимита на размер строки теперь будет приводить к выводу предупреждения при сборке только если утилита checkpatch запущена с опцией "–strict’. Изменение даст возможность не отвлекать разработчиков на манипуляции с пробелами и более свободно чувствовать себя при выравнивании кода.

      Нагло стырено с opennet.ru

Всё? Конец эпохи консоли и 80х25?
Кто придерживался выравнивания в 80 символов?
Заметил, что по умолчанию в редакторах предлагают диапазон от 80 до 120 для показа границы.

И интересно, каким типом выравнивания пользуются? Станет ли код читабельнее? Стоит ли вводить стиль на 100? На 120? С железом проблем нет, 4к мониторы, широкоформатные, 4:3, любые.



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

странно, что до 100 увеличили, а не сразу до 120. Но всё равно приятные подвижки :)

v9lij ★★★★★
()

Бред же, это C++ники с их километровыми именами функций мину подложили. И «индусы», которые не могут в табы. Невозможно же читать.

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

Просто у плюсов больше сфера прикладного и околосистемного ПО, чем у C. А ядерная базовая терминология ограничена и давно изучена. Например, все знают, что такое дескриптор, будь он dscr или MySuperDescriptor. «Индусы» тут вообще ни при чем.

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

Просто культура кодинга в среднем сильно упала за последние годы и падает дальше, и открытым проектам приходится идти за модой, так как где же тогда брать кодеров, если правильные кончились?

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

И это, к сожалению, правда. Я думаю, что данное утверждение касается не только IT отрасли. Помню, что в советские времена всё нужно было «доработать», игрушку, танк, манипулятор, велик. Зато давало абстрактноен представление о устройстве, воображение для починки подручными материалами. Теперь, особенно в JS мире, на каждый чих библиотека. Чёрт меня дёрнул глянуть код…

Vault_Boy
() автор топика

эх, ушла эпоха…
началось с 80-столбцовых перфокарт
продолжилось стандартом фортрана, который был привязан к 80-столбцовому написанию (точнее, к 72, но это не важно)
потом появились 80-столбцовые принтеры
потом 80-столбцовые текстовые дисплеи
и даже в графических видеокартах был оставлен текстовый формат 80*25
и до сих пор глупые почтовые программы зачем-то разбивают строку, если она длиннее 80 символов
и всё, теперь «ненужно»?

правда, лично я это ограничение в 80 символов ненавидел ))))

а если в будущем станут распечатывать программы на туалетной бумаге, то там опять будет 80 символов )))
зачем распечатывать? ну, вместо того, чтобы хранить весь гитхаб в замороженной шахте, можно просто распечатать всё это на туалетной бумаге и пустить в продажу. в случае апокалипсиса это «ценное наследие» будет спасено, хоть у кого-нибудь да останется «непротёртое».

Egor_
()
Последнее исправление: Egor_ (всего исправлений: 4)
Ответ на: комментарий от RazrFalcon

Тут не про компиляторы (хотя когда там 6 символов то было?) а про вид кода. На код многих проектов без настроенного под проект IDE смотреть вообще небезопасно для психики. Короткие строки улучшают чтение кода. Читаемость кода вообще-то важна. Что бы там новое поколение ни думало. Я постоянно сталкиваюсь с тезисом о том, что то, что программист не должен понимать чужой код и это норма. К чему в итоге это все приведет - боюсь даже представить.

slapin ★★★★★
()

Всё? Конец эпохи консоли и 80х25?

80x24 же!

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

Короткие строки улучшают чтение кода.

ну давайте тогда сделаем строки вообще по 50 символов, чтобы еще лучше читалось.

Чисто для примера, попробуй пописать код с libsodium. Там сплошь и рядом дефайны вроде crypto_box_SECRETKEYBYTES - я вот не представляю, как там можно наваять что-то читаемое с шириной 80.

Lrrr ★★★★★
()
Последнее исправление: Lrrr (всего исправлений: 1)
Ответ на: комментарий от Lrrr

Там сплошь и рядом дефайны вроде crypto_box_SECRETKEYBYTES - я вот не представляю, как там можно наваять что-то читаемое с шириной 80.

А ты его передефайнь!
#define cbSKB crypto_box_SECRETKEYBYTES
Если у людей читаемость кода измеряется в длине строки, то ССЗБ )))

Egor_
()
Последнее исправление: Egor_ (всего исправлений: 1)
Ответ на: комментарий от slapin

Все таки культура (чего-либо) общирное понятие, и я не стал бы в одну кучу кидать и именование идентификаторов, и другие аспекты кодинга.

У сокращенной схемы именования переменных были об’ективные технические причины - маломощность и скудность доступных ресурсов тогдашних компов по сравнению с современными, и соответственно, ограничения компиляторов. Если бы тогда вместо PDP* были пентиумы, и у компиляторов того же фортрана и интерпретаторов бейсика не было ограничений на длину идентификаторов, никто бы не писал tmpbuf, а писали бы, например, TempBuffer. Плюс, некоторые особенности именования идентификаторов были привязаны к конкретному языку, например, lp (от «long pointer»), очевидно, не имеет никакого смысла за пределами языков без указателей.

Дальше те, кто писал системный софт, тупо, привыкши к древним правилам именования, не хотели ничего менять. Но это не значит, что поколение пентиумов не умеет писать системный софт - просто пока проекты контролируются людьми поколения Торвальдса, им так удобно, и они это всем новичкам навязывают просто потому что они условные батьки, а кругом сосунки. Но по сути сейчас это чисто привычка и эстетика.

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

На код многих проектов без настроенного под проект IDE смотреть вообще небезопасно для психики

Это всё из паганых табов.

RazrFalcon ★★★★★
()

80 символов для современных разрешений реально мало, так что поддерживаю нововведение

neocrust ★★★★★
()

Использую 120, потому что остается достаточно места справа для предупреждений clang в QtCreator, и можно комфортно работать в разделенном по вертикали экране (FHD) с 2-мя файлами. А когда нет предупреждений и нет нужды работать сразу с 2-мя файлами, то можно просто на пол экрана открыть лор и строчить жалобы на неугодные аватарки с фотожабами пуятишны

SR_team ★★★★★
()
Последнее исправление: SR_team (всего исправлений: 1)
Ответ на: комментарий от rupert

ну там вообще однобуквенные жмотяры
с таким кодом и обфускация не нужна

Egor_
()
Ответ на: комментарий от slapin
public Page<DispatchSchedule> findBySalesOrderItemSalesOrderCustomerAndDispatchScheduleDateBetweenAndJob(Customer customer, Date startDate, Date endDate, Job job, Pageable pageable) {
return repository.findBySalesOrderItemSalesOrderCustomerAndDispatchScheduleDateBetweenAndJob(customer, startDate, endDate, job, pageable);
}
Fast_Sloth
()
Ответ на: комментарий от slapin

так как где же тогда брать кодеров, если правильные кончились?

Каких учили, таких и получайте.

Lzzz
()

Я вижу две проблемы:

  • Чем больше максимальная длина строки тем больше места тратится впустую, потому что большинство строк остаются короткими. В большинстве конфигураций с горизонтальным монитором 80 против 100 символов это 3 против 2 колонок с кодом.
  • Чем длиннее строки, тем сложнее читать код и диффы на портативных устройствах

Никаких 80 колонок уже давно не существует, но то что чем компактнее код во все стороны тем он читабельнее фактом быть не перестало, и современные языки (кроме нескольких уродов) гораздо более ёмки и компактны чем старьё из прошлого века, так что объективной надобности в длинных строках нет.

Поэтому я склоняюсь к тому чтобы поддержать ограничение в 80 символов. А может даже и меньше.

slovazap ★★★★★
()

В Talks'ах есть вторая такая же тема, где уже всё обсудили: Предлагаю обсудить главную новость ядра. .

На самом деле, мониторы 1280x1024 сегодня встречаются не так уж и часто, но даже на них нет проблем с редактированием длинных строк. А на FullHD мониторах даже для ядерной консоли нормой является ширина строки, например, в 120 символов.

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

Да давайте впихивать в имя пременной сразу документацию с комментариями! Ведь иначе точно никто не догадается что такое utlIntNonzeroTemporaryCounter.

slapin ★★★★★
()

Как-то они на полшишечки. Ставили бы уж сразу 120.

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