Comments 171
отличная статья! обычно у вас так себе объекты для проверок, а тут прям интересный объект взяли. отлично.
и авторы np++ тоже молодцы — ошибки прям такие… для учебника.
а вы отправили авторам полный список обнаруженных проблем?
и авторы np++ тоже молодцы — ошибки прям такие… для учебника.
а вы отправили авторам полный список обнаруженных проблем?
Сейчас отправлю, мы всегда это делаем. Дополнительно пару мест сам поправлю для Pull Request'а.
Без этого стабильного вопроса статья от авторов PVS-Studio была бы неполной.
А ещё каждый раз интересно — проверяют ли они код анализатора своим анализатором.
Конечно проверяем. Поэтому нет и не может быть статьи о проверке C++ ядра анализатора, потому что анализатор с самого начала используется и количество предупреждений всегда должно быть равным нулю. Если разработчики что-то сами находят, то исправляют это до закладывания кода.
В следующий раз буду поднимать табличку «сарказм» :)
Ну вы же не проверяет анализатором 2017го года код 2007го. Машины времени у вас нет.
Так что статья, рассказывающая, какие новые диагностики стриггерились на вашем кода, скажем, пятилетней давности — была бы интересна.
Понятно что она слишком многое расскажет о вашей кухне, так что, рассчитывать на неё не приходится… Но помечтать-то можно?
Так что статья, рассказывающая, какие новые диагностики стриггерились на вашем кода, скажем, пятилетней давности — была бы интересна.
Понятно что она слишком многое расскажет о вашей кухне, так что, рассчитывать на неё не приходится… Но помечтать-то можно?
Статьи о старом коде будут крайне непопулярны.Есть много нового когда, где ещё никто не нашёл ошибки)
Когда была возможность, проверяли плагин PVS-Studio с помощью PVS-Studio.
Понятно что она слишком многое расскажет о вашей кухне, так что, рассчитывать на неё не приходится… Но помечтать-то можно?
Когда была возможность, проверяли плагин PVS-Studio с помощью PVS-Studio.
В статье об истории нашего продукта мы проверяли первую версию анализатора. Думаю это то, что нужно.
Я извиняюсь, мог пройти мимо, но не удержался.
Кому-то до сих пор интересно читать обзоры проверок программ?
Может стоить подумать над другим форматом подачи PVS?
я не знаю каким.
Поначалу читал такие обзоры, потом понял, что они почти все однообразные.
Кому-то до сих пор интересно читать обзоры проверок программ?
Может стоить подумать над другим форматом подачи PVS?
я не знаю каким.
Поначалу читал такие обзоры, потом понял, что они почти все однообразные.
А может стоит учесть что представляет из себя PVS? Лучшей подачи и быть не может. Кроме того что идет реклама продукта, можно насладиться интересным разбором с отличным оформлением.
Типичное — мне не интересно, значит оно неинтересно всем.
Мне интересно.
По себе заметил, что после этих статей выработался полезный скилл быстро делать ревью на ТОП-100 типичных ошибок и находить их.
По себе заметил, что после этих статей выработался полезный скилл быстро делать ревью на ТОП-100 типичных ошибок и находить их.
Эк заминусовали-то. Мне в целом интересно почитать, что ещё накопали, но в чём-то kravtsov_dim прав. Например, разделы про "The 'pScint' pointer was utilized before it was verified against nullptr" я пролистываю, потому что такое реально в каждой статье есть и в каждой программе с 10-15-летней историей можно отыскать подобное. Это скучно. Но есть интересные ошибки и особенности C++, о которых я не знал (потому что не пишу на нём). Например, про ловлю исключений по значению. Пара интересных ошибок — уже не зря статью прочитал :-)
… разделы про «The 'pScint' pointer was utilized before it was verified against nullptr» я пролистываю ...
… Но есть интересные ошибки и особенности C++, о которых я не знал ...
У всех скил разный, то что знает один может быть интересно другим.
У всех скил разный, но о первом нельзя не знать, если вы видели хотя бы пару предыдущих статей в таком формате от PVS-Studio. Конечно, каждая статья может для кого-то оказаться первой.
Можно тоже самое сказать про утечки памяти(все, я думаю, знают, что перед любым return'ом в функции/методе стоит удалять все динамические объекты/выделенную память, указатели на которые были локальными в функции/методе), и многие другие банальные ошибки. На мой взгляд отображение таких ошибок в статьях позволяет понять, что какими бы глупыми не казались ошибки, это не спасает от их появления в продакшене любых проектов.
Но согласитесь приятно смотреть на чужую глупость, пока у себя подобное однажды не найдешь)
Но согласитесь приятно смотреть на чужую глупость, пока у себя подобное однажды не найдешь)
UFO just landed and posted this here
Статистика GitHub говорит что пробелы гораздо популярнее
А знаете почему? Из-за отсутствия стандартизации. Вот пишет автор код с выравниваем, поставил две табуляции, а остальное догнал пробелами, у него все красиво и аккуратно. Откроет этот файл другой человек в другом редакторе, а у него табуляция отображается как 5-ть пробелов, а не 4-ре как у автора и все форматирование поплыло. Или бывают редакторы которые табуляцию отображают не просто в виде N-пробелов, а в виде N-пробелов с учетом сроки выше / ниже.
Если с шириной символов уже проблем в 99% случаев нет (ибо моноширинный это стандарт де-факто), а вот с табуляцией будут проблемы, если код публичный, а не в рамках одной компании и одного инструментария.
Если с шириной символов уже проблем в 99% случаев нет (ибо моноширинный это стандарт де-факто), а вот с табуляцией будут проблемы, если код публичный, а не в рамках одной компании и одного инструментария.
Откроет этот файл другой человек в другом редакторе, а у него табуляция отображается как 5-ть пробелов, а не 4-ре как у автора и все форматирование поплыло.Вот из-за таких как вы всё и ломается. Табуляция — это 8 пробелов.
А я тут при чем? У меня в medit тоже 8, в какой-то IDE 4 видел. Это значения по умолчанию были.
1-н таб состоит из 4-х пробелов.
Это у кого они из 4-х пробелов состоят? Изначально (на пишущих машинках) они 5 пробелов занимали, когда их адаптировали для компьютеров, то принтеры в течение десятилетей поддерживали только и исключительно восемь (до восьми считать удобнее). А 4 — это как раз и есть «начало конца», когда «всё смешалось».
Так как мы, всё-таки, работаем с компьютерами, а не с ремингтоновскими машинками, то в табе — 8 пробелов.
Так как мы, всё-таки, работаем с компьютерами, а не с ремингтоновскими машинками, то в табе — 8 пробелов.
«до восьми считать удобнее» — это почему?
в Visual Studio по дефолту 4 пробела
https://stackoverflow.com/questions/14167033/visual-studio-replace-tab-with-4-spaces
в Visual Studio по дефолту 4 пробела
https://stackoverflow.com/questions/14167033/visual-studio-replace-tab-with-4-spaces
«до восьми считать удобнее» — это почему?Транзисторов/реле меньше нужно (да-да — этот старднарт появился в эпоху электромеханических устройств, в частности вот таких вот принтеров).
в Visual Studio по дефолту 4 пробелаВ этом, собственно, и проблема: Microsoft, как обычно, проигнорировал то, что десятилетиями делалось до появления Visual Studio и изобрёл свой стандарт.
8 пробелов — это жесть жестяная. Поддерживаю майкрософт. 4 пробела, а лучше — 2.
Размер отступа не имеет никакого отношения к размеру таба. Размер таба в 8 символов — это просто свойство текстового формата.
Возьмите какой-нибудь язык, где отступы важны (скажем Python) — там у вас отступ из одного таба будет считаться больше, чем из семи пробелов, но меньше, чем из девяти — вот и всё.
А уж какой отступ вам нравится — это ваше личное дело.
Возьмите какой-нибудь язык, где отступы важны (скажем Python) — там у вас отступ из одного таба будет считаться больше, чем из семи пробелов, но меньше, чем из девяти — вот и всё.
А уж какой отступ вам нравится — это ваше личное дело.
Поправьте меня, но в VS вместо табуляции срабатывает автозамена на 4 пробела, а тут речь, как я понимаю, идет о размере самой табуляции в редакторах…
К слову: именно из-за таких неожиданных поворотов я и перестал использовать табуляцию и перешел на пробелы. Особенно было проблемно смотреть файлы с табуляцией в том же Vim'e в консоли, когда 4 уровень уползал почти на половину экрана.
К слову: именно из-за таких неожиданных поворотов я и перестал использовать табуляцию и перешел на пробелы. Особенно было проблемно смотреть файлы с табуляцией в том же Vim'e в консоли, когда 4 уровень уползал почти на половину экрана.
Так как мы, всё-таки, работаем с компьютерами, а не с ремингтоновскими машинками, то в табе — 8 пробелов.
Глупости пишете. В табе нету пробелов. Таб — это таб, один символ и неважно, какая у него ширина.
Это — новомодное изобретение и попытка «переосмыслить» старую добрую концепцию, которой скоро сто лет исполнится.
Не надо так. Хотите ввести какие-нибудь «элестичные табы» — вводите. Тоько не стоит их с традиционными путать.
Не надо так. Хотите ввести какие-нибудь «элестичные табы» — вводите. Тоько не стоит их с традиционными путать.
Я что-то не вижу в вашей концепции ничего про ширину. В том же Ворде ширина табов точно так же эластична.
В печатном деле ширина табов была неэластична исключительно в силу механических ограничений. Отталкиваться от того, что там было в эпоху печатных машинок не имеет смысла, потому что сейчас это не так.
Таб — один символ, всё. Попытки захаркодить его с пробелами — это просто глупость. Это не может быть предметом холивара, потому что это вкусовщина и каждый настраивает его ширину по своему. Я вот люблю табуляцию шириной в три пробела. Но на любой ширине мой код будет выглядеть корректно.
В печатном деле ширина табов была неэластична исключительно в силу механических ограничений. Отталкиваться от того, что там было в эпоху печатных машинок не имеет смысла, потому что сейчас это не так.
Таб — один символ, всё. Попытки захаркодить его с пробелами — это просто глупость. Это не может быть предметом холивара, потому что это вкусовщина и каждый настраивает его ширину по своему. Я вот люблю табуляцию шириной в три пробела. Но на любой ширине мой код будет выглядеть корректно.
В том же Ворде ширина табов точно так же эластична.Нет. Она зафиксирована для конкретного документа. Даже в ворде.
Отталкиваться от того, что там было в эпоху печатных машинок не имеет смысла, потому что сейчас это не так.Это и сейчас так. Вот вы тут подняли Ворд. Ok. Где там можно выставить размер таба? Не для конкретного документа, а «вообще» — так, чтобы он действовал на все документы?
Это не может быть предметом холивара, потому что это вкусовщина и каждый настраивает его ширину по своему.Формат текстовых файлов, увы и ах, не предусматривает места, где это можно указать. HTML — предусматривает, но даже там — это свойство документа (вернее наложенного на него стиля), а не «хотелки» читателя. И умолчание — там всё равно 8, а не 5, 4, или, прости госсподи, 2.
Я вот люблю табуляцию шириной в три пробела.Это ваше право. Любите. Но не в текстовых документах, пожалуйтста.
Но на любой ширине мой код будет выглядеть корректно.Это ваше прово — тратить время и силы на то, чтобы картины «из рисовых зёрнышек» складывать. Мне этим заниматься, если честно, лень. За меня это clang-format делает — в нём есть опция UseTab.
Видите ли, мы говорим о рабочем инструменте. Он выполняет определенные функции. И должен соответствовать определенным условиям — удобству, семантике и т.п, а не тому, как хочет какой-то Кхим, потому что где-то в другом месте табы используются иначе.
Жаль вас огорчать, но правила верстки печатных текстов не распространяются на правила оформления кода.
Жаль вас огорчать, но правила верстки печатных текстов не распространяются на правила оформления кода.
Видите ли, мы говорим о рабочем инструменте.Видите ли — но мы говорим, прежде всего, о некотором формате файла. В данном случае — текстовом. В нём — табы имеют фиксированную ширину. 8 символов.
Всё что вы хотите «навернуть» сверху, сбоку, справа, слева — следует уже после этого.
Он выполняет определенные функции.Именно.
И должен соответствовать определенным условиям — удобству, семантике и т.п, а не тому, как хочет какой-то Кхим, потому что где-то в другом месте табы используются иначе.Первое и самое главное требование — он должен быть интерепретирован каким-то определённым способом. И так исторически сложилось, что в текстовых файлах таб стопы расставлены через 8 символов и также исторически сложилось, что многие языки программирования используют текстовые файлы для хранения текста. Всё остальное — навешивается над этой конструкцией «сверху».
Жаль вас огорчать, но правила верстки печатных текстов не распространяются на правила оформления кода.А вот требования к форматам файлам — распространяются. Python — хороший тому пример.
Вы так любите на докомпьютерную историю ссылаться. Так вот, к вашему сведению, на печатных машинках как раз табы были "эластичными". Там были линейки по которым можно было двигать стопоры. И таб сдвигал каретку до следующего стопора.
Что касается питона, то вы тоже неправы:
Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case.
В данном случае — текстовом. В нём — табы имеют фиксированную ширину. 8 символов.
Ошибаетесь. В нем таб — это один символ \t и у него нету ширины.
так исторически сложилось, что в текстовых файлах таб стопы расставлены через 8 символов и также исторически сложилось
Вы вот раз за разом это повторяете. Но ваша проблема в том, что вы путаете понятия. Так не «исторически сложилось», а «так когда-то было». Сейчас объясню.
Да, возможно, когда-то давным-давно табы были 8 символов и ими удобно было выравнивать таблицы, но… (а теперь внимание)… так исторически сложилось, что теперь в разных редакторах разные настройки. Кто-то ставит себе таб 8 символов, кто-то 4, кто-то 3, кто-то 2. Вот именно это «исторически сложилось».
И теперь, учитывая этот факт можно понять, что даже если когда-то было, что таб использовался для выравнивания таблиц, то теперь его уже так нельзя использовать, потому что так исторически сложилось, что у разных людей на разных устройствах ширина будет совершенно разной.
А вот использование таба как я предлагаю — никак не зависит от «исторически сложенного» плавающего размера таба. Так как при любом размере таба будет только изменяется ширина отступа, но не будет ломаться его логическая структура.
При вашем же использовании, увы, но на разных настройках будет сбиваться структура и ваша таблица будет превращаться в кашу. Потому вариантов нету и необходимо выравнивать ее пробелами. А ваша захардкодженность на настройки по-умолчанию в некоторых редакторах — это жуткий, плохо работающий костыль.
Нет. Она зафиксирована для конкретного документа. Даже в ворде.Откройте ворд и посмотрите на поведение табуляции. Откроете много нового для себя. Например, что табуляция хранится в виде <w:tab/>(действительно, 8 символов =\ ) и выставляется в сантиметрах. Или что табуляция состоит из 4 букв «Ш», но из семи символов "!". А при изменении размера шрифта — из 4 единиц и 2 букв «Ш». При этом, в табуляцию помещается не целое число символов. Или что табуляция — не синоним сноски слева, которая является параметром абзаца. Или что после удаления стилей из документа отображение документа зависит от настроек Word'а.
И самое страшное, текстовые процессоры не открывают файлы .cpp\.java\.py\.css. Импортируют текст, да, но не открывают. Вот и не надо нам натягивать правила какой-то левой среды. Мы код пишем не для того, чтобы его на принтерах печатать, а для чтения нами же. И у нас табуляция — один символ 0x09, а как его отображать — целиком зависит от контекста.
А то, что в допотопных матричных принтерах табуляция была 8 символов, так это тоже выставлялось в параметрах драйвера принтера, и далеко не у всех были именно 8 по умолчанию.
Не будет, если смешано с пробелами, а смешивать приходится, если нужно выравнивать, например, под скобки для аргументов функции, а без выравнивания опять же некрасиво. За пробелы!
Вот из-за редакторов, чьи авторы считают так же, я и разлюбил табы. Какие-то пять уровней вложенности (а это всего лишь пространство имен, класс, метод, цикл и условный оператор) — и строки кода уже с середины экрана начинаются...
Почему-то все про 4, 5 и 8 говорят. По-моему, идеальный отступ — два пробела. Один можно не заметить в некоторых случаях, а два в глаза бросается и при этом драгоценное место на экране не тратится.
Потому что табы — не отступы. Они предназначены для создания таблиц (даже из названия ясно). Изначально — они были в 5 символов (на механических пишущих машинках), потом их решили расширить до 8 символов.
И только уже ближе к XXI веку разработчики некоторых редакторов решили всё «учучшить» и сотворили «чудо-юдо» в 4 символа.
Два символа на таб смысла не имеют — проще два пробела поставить.
И только уже ближе к XXI веку разработчики некоторых редакторов решили всё «учучшить» и сотворили «чудо-юдо» в 4 символа.
Два символа на таб смысла не имеют — проще два пробела поставить.
Это, кстати, тема для отдельного холивара — отступы на неймспейс и внешний класс, если он один в файле. Не понимаю, зачем бесполезно тратить два отступа практически на весь код файле. Считаю, что это отдельный котёл и всё такое.
Потому что для отступов нужно использовать табы (чтобы показать уровень вложенности), а для выравнивания — пробелы. В итоге и не плывёт ничего ни у кого, и настроить комфортный размер отступов можно.
Я не понимаю что вы подразумеваете под выравниванием.
Первое что попалось под руку в качестве примера:
То есть уровни вложенности делаем табами, а внутри строки если что-то надо выровнять что-то — то уже пробелы. В некоторых редакторах такое поведение можно сделать автоматическим, чтобы в зависимости от места в строке кнопка tab вставляла или табы, или пробелы.
То есть уровни вложенности делаем табами, а внутри строки если что-то надо выровнять что-то — то уже пробелы. В некоторых редакторах такое поведение можно сделать автоматическим, чтобы в зависимости от места в строке кнопка tab вставляла или табы, или пробелы.
Только обычно никто не соблюдает, и большую часть выравнивания забивают табами, а остаток добивается пробелами. В результате и получается… Не понимаю, почему нельзя использовать просто пробелы. В современных IDE при редактировании разницы не увидишь, экономить байты в исходниках в наше время — смешно.
В современных IDE при редактировании разницы не увидишьАга-ага. Попробуйте в Makefile заменить табы на пробелы — а я над вами посмеюсь.
UFO just landed and posted this here
Makefile — велосипедный анахроизм, написанный на коленке по принципу «лишь бы один раз отработало, все равно на выброс»Ну да, конечно. Программу, пережившую многих тут дискутирующих, оказывается на «лишь бы отработало, всё равно на выброс» писали.
На самом деле в те времена в этом был очень даже практический смысл: устройствами ввода-вывода служили телетайпы, скорость передачи данных была 300 (или уже 600?) бод и разница в использовании табов и пробелов вполне себе была видна «невооруженным глазом».
Однако в сегодняшних реалиях, соглашусь, вариант использования пробелов везде и всюду — вполне имеет право на жизнь. А вот устраивать чёрт знает что с переменными размерами табуляций — не стоит.
Попробуйте в Makefile заменить табы на пробелы — а я над вами посмеюсь.
В GNU make это настраивается, кстати.
Только обычно никто не соблюдает
Это уже недостатки программистов, а не табов.
Табы лучше, ибо:
1. Удобнее перемещение стрелочками
2. Нельзя поставить курсор в середину отступа
3. Семантика
4. Возможность каждому программисту настроить под свой вкус
5. Возможность в IDE включить отображение табов и видеть реальную глубину отступа
Экономия байтов — это скорее может применятся как шуточный аргумент, в том числе в сериале.
В то время, как у пробелов из преимуществ — только «есть программисты, которые не могут осознать простые правила». Но это легко обходится code-review за один день.
Так что я не понимаю, почему нельзя просто использовать табы)
1. Удобнее перемещение стрелочкамиКто тут говорил об ограничениях инструментов? Да даже в каком-нибудь убогом Midnight Commander'е есть режим когда всё это работает с пробелами, менять понятие понятия «таб» для этого не нужно. А вот если вы выравниваете текст в серединие, то вам удобнее, чтобы табы имели размную ширину — 8 вполне годится.
2. Нельзя поставить курсор в середину отступа
3. Семантика
4. Возможность каждому программисту настроить под свой вкусНе работает. Экран, увы и ах, имеет фиксированную ширину, потому невозможно вписать в него текст не зафиксировав размер таба. Зафиксировав же размер таба мы обнаружим, что нам неважно — каков он конкретно. И тогда непонятно — почему не использовать умолчальное значение в 8 пробелов, а пытаться совершить никому ненужную революцию.
5. Возможность в IDE включить отображение табов и видеть реальную глубину отступаОпять-таки — непонятно зачем для этого менять формат файла. IDEA вполне может рисовать вертикальные линии, которые ну никак не хуже табов.
Так что я не понимаю, почему нельзя просто использовать табы)Я тоже. Я их регулярно использую, когда размешаю в комментариях таблицы, например. Редактировать — реально удобнее.
А вот если вы выравниваете текст в серединие, то вам удобнее, чтобы табы имели размную ширину — 8 вполне годится.
А еще сгодится 2, 3 или 4.
Экран, увы и ах, имеет фиксированную ширину, потому невозможно вписать в него текст не зафиксировав размер таба
Глупость
почему не использовать умолчальное значение в 8 пробелов
Потому что это неважно. Можно использовать любое.
Опять-таки — непонятно зачем для этого менять формат файла
Формат файла не меняется. Вы сегодня прям в ударе.
А еще сгодится 2, 3 или 4.4 ещё, может быть, сгодился бы, но 2-3 — слишком мало. Очень узкие колонки получаются. Нет большого выигрыша по сравнению с пробелами.
ГлупостьО, уже на личности переходим.
Потому что это неважно. Можно использовать любое.Для того, чтобы выравгивать текст в несколько колонок? Ню-ню.
Формат файла не меняется.Как это «не меняется»? Вы «забрали» один символ и вместо значения, которое у него было последние полвека (с середины 60х) начинаете упорно навязывать ему какие-то другие варианты.
О, уже на личности переходим.
Это не личности, я оценил вполне определенную фразу, а не вас.
Остальное — уже нный круг.
Остальное — уже нный круг.Где конкретно вы обьяснили как жить с не умещающимся на экран кодом? Кроме я открываю в редакторах, которыми пользуюсь, а там всё нормально настроено я ничего не приминаю, как бы. А этот подход — равносилен поражению, так как единственное неоспоримое «преимущество» подхода «indent with tabs, align with spaces» — это возможность использовать такой отступ, какой вам хочется… но если это не работает (а это не работает) — то какой вообще во всей это конструкции смысл?
Все остальные псевдопреимущества достижимы в рамках модификации IDE и не требуют переосмысленного трактования понятия «текстовый файл».
1. Удобнее перемещение стрелочкамиДля начала убираем подальше мышь, и вспоминаем о волшебной клавише Ctrl.
2. Нельзя поставить курсор в середину отступа
3. СемантикаСекунду, мы код пишем или семантически грамотно используем знак табуляции для отображения табличных данных?
4. Возможность каждому программисту настроить под свой вкусСомнительное «преимущество» учитывая сколько проблем за собой несет.
5. Возможность в IDE включить отображение табов и видеть реальную глубину отступаКак уже ответили часть IDE прекрасно отображает уровни вложенности при использовании пробелов.
К слову о стандартах: у PHP'шников есть такая штука как PSR. В PSR-2 четко регламентируется стиль оформления кода:
Code MUST use 4 spaces for indenting, not tabs.
О пробелах и табуляции. Попробуйте открыть тот же cpp файл в различных текстовых редакторах/ide особенно когда дело доходит до глубокой вложенности и вся эта табуляция переносит код на средину окна редактора. Вот и вспоминаешь потом людей добрыми словами. Что мешает использовать пробелы? К тому же большинство ide прекрасно умеют при нажатии на Tab ставить 4 пробельных символа.
Для начала убираем подальше мышь, и вспоминаем о волшебной клавише Ctrl.
Зачем убирать мышь? Удобный дополнительный инструмент. Из-за кризины использования пробелов?
Сомнительное «преимущество» учитывая сколько проблем за собой несет.
Нисколько.
К слову о стандартах: у PHP'шников есть такая штука как PSR. В PSR-2 четко регламентируется стиль оформления кода:
Сочувствую пхпшникам.
Попробуйте открыть тот же cpp файл в различных текстовых редакторах/ide особенно когда дело доходит до глубокой вложенности и вся эта табуляция переносит код на средину окна редактора
Что? Я открываю в редакторах, которыми пользуюсь, а там всё нормально настроено.
Что мешает использовать пробелы?
Вы повторяетесь.
К тому же большинство ide прекрасно умеют при нажатии на Tab ставить 4 пробельных символа.
Или ставить символ табуляции.
Зачем убирать мышь? Удобный дополнительный инструмент. Из-за кризины использования пробелов?Я не буду Вас призывать освоить столь чудные инструменты как командные текстовые редакторы(к примеру Vim), которые позволяют при должном навыке писать код быстрее. Но даже в ide я не вижу смысла убирать вторую руку с клавиатуры для позиционирования курсора(к слову Вы сами про стрелки разговор начали, Ctrl+стрелки позволяют быстрее позиционировать, чем использование табуляции и просто стрелок).
Что? Я открываю в редакторах, которыми пользуюсь, а там всё нормально настроено.Я рад за Вас, но иногда для редактирования пары строк легче открыть даже примитивный блокнот, чем загружать ради этой цели тяжелую IDE.
Или ставить символ табуляции.теперь уже Вы повторяетесь.
Но даже в ide я не вижу смысла убирать вторую руку с клавиатуры для позиционирования курсора
Есть моменты, когда удобнее использовать клавиатуру, а есть моменты, когда удобнее использовать мышь. Это инструменты для слегка разных целей.
Я рад за Вас, но иногда для редактирования пары строк легче открыть даже примитивный блокнот, чем загружать ради этой цели тяжелую IDE.
Открою вам секрет, но есть непримитивные блокноты и, при они с настройками и даже работаю быстрее примитивного. Мне вообще непонятно, как кто-то ещё может пользоваться блокнотом по-умолчанию
теперь уже Вы повторяетесь.
Ну да, мы замкнулись)
Есть моменты, когда удобнее использовать клавиатуру, а есть моменты, когда удобнее использовать мышь. Это инструменты для слегка разных целей.Есть, не спорю, но началось то все с:
1. Удобнее перемещение стрелочкамиСтрелками удобнее с Ctrl передвигаться(хотя о вкусах не спорят), а ему все равно 1 знак табуляции или 2-4-8-16(или сколько там набралось) пробельных символов подряд.
2. Нельзя поставить курсор в середину отступа
Открою вам секрет, но есть непримитивные блокноты и, при они с настройками и даже работаю быстрее примитивного. Мне вообще непонятно, как кто-то ещё может пользоваться блокнотом по-умолчаниюБлокнот был назван со словами «легче открыть даже примитивный блокнот», что подразумевало использование блокнота в качестве примера. Для просмотра/внесения мелких правок исходников достаточно простого текстового редактора, и далеко не каждый текстовый редактор готов отображать символ табуляции так, как хотел бы пользователь.
Я не сторонник использования табуляции для отображения уровней вложенности кода. Табуляция всегда использовалась для табличных данных и мне не хотелось бы видеть как один текстовый редактор отображает данный символ по своему, а другой — по своему.
Ну да, мы замкнулись)Предлагаю закончить этот спор: мне не понять Ваше желание иметь возможность редактировать размер табуляции, Вам не понять моей нелюбви к отступам в виде символа табуляции.
Но даже в ide я не вижу смысла убирать вторую руку с клавиатуры для позиционирования курсора
Команды главного меню, контекстного меню, выделение строки в списках типа git log или в окне результатов поиска, прокрутка колесиком или перетаскиванием вместо PgUp/PgDown, переключение через трей или панель задач. Когда рука уже на мышке, удобнее сразу тыкнуть куда надо.
Не отрицаю, мы просто ушли от первоначального высказывания, на которое я сослался выше.
Учитывая контекст Вы хотите сказать, что позиционируя курсор мышкой при использовании пробелов, есть большая доля вероятности поставить его в середину отступа?
Учитывая контекст Вы хотите сказать, что позиционируя курсор мышкой при использовании пробелов, есть большая доля вероятности поставить его в середину отступа?
Как перемещение может быть удобнее? Вот у меня курсор стоит в <|footer> и я хочу его перевести в <|/footer>. Я нажимаю четыре раза кнопку вниз, а курсор начинает при этом ещё влево-вправо скакать, отвлекая меня от сути моего действия. Это удобно?
Да, вполне. Вот пример из Notepad++:
Основное преимущество, что при таком способе курсор не может стать в середину символа.
Основное преимущество, что при таком способе курсор не может стать в середину символа.
Так я и говорю, что скачет влево-вправо. И на вашей гифке именно влево-вправо и скачет, а не только идёт вверх-вниз. Что вы мне хотите этим показать из того, что я ещё не сказал?
Главное, что он стает туда, куда необходимо. Да, не отвлекает, да удобно. Значительно менее удобно и больше отвлекало бы, если бы он внезапно оказывался посреди символа, вот это действительно отвлекает.
Когда я просто прохожу мимо этого места мне как-то наплевать, есть там табуляция или нет, я просто мимо проходил. Как это может действительно отвлекать?
Вы же сами сказали, что вас там что-то отвлекает:
Вы очень непоследовательны.
курсор начинает при этом ещё влево-вправо скакать, отвлекая меня от сути моего действия
Вы очень непоследовательны.
На самом деле lany вполне последователен. Но проблема в другом: есть редакторы, которые вполне могут делать то, чего вы хотите, в файлах, отформатированных с помощью пробелов, можно представить себе редактор, который будет вести себя так, как хочет lany в файлах, где используются табы (вставляя при необходимости нужное число пробелов), менять ради этого весь мир, как предлагаете вы, для этого не требуется.
менять ради этого весь мир
Вы — не мир, слишком много на себя берете.
Менять мне ничего не надо. Мир уже давно живет по двойственным правилам.
Вы — не мир, слишком много на себя берете.Я — нет, но если сложить вместе разработчиков Android'а и GCC, Ghome и Notepad++, вот этих вот всех проектов, где «поставил две табуляции, а остальное догнал пробелами, у него все красиво и аккуратно» — то примерно так и наберётся если не весь мир, то полмира точно.
Менять мне ничего не надо. Мир уже давно живет по двойственным правилам.Возможно ваш мирок и живёт по «двойственным правилам», но я не видел ни одного проекта достаточно большого размера, где бы практиковался продвигаемый вами «новаторский подход». Я когда писал расскажите уж о проектах с числом разработчиков от тысячи и числом строк от 10 миллионов где используется ваша технология — это без сарказма делал.
Ибо пока что я реально встречал ваш «новаторский» подход только в мелких проектах — притом, что, якобы, смысл заключается именно в том, что позволяет привлечь кучу народу… так почему же этого не происходит?
Потому что вам нравятся отступы в 2 символа, мне нравятся в 4 символа, Пете нравятся отступы в 8 символов, а кому-то подавай 3 символа. Именно поэтому пробелы для отступов — это отстой. Потому что они лишают возможности смотреть код так, как удобно именно вам.
Потому что вам нравятся отступы в 2 символа, мне нравятся в 4 символа, Пете нравятся отступы в 8 символов, а кому-то подавай 3 символа.Это такая же вкусовщина как Camel Case против Snake Case и прочего. Автор кода решает.
Потому что они лишают возможности смотреть код так, как удобно именно вам.Ага. Давайте ещё CSS к текстовым файлам прикрутим. Тестовые файлы хороши своей простотой и однозначностью. Не нужно их усложнять без необходимости.
Ага. Давайте ещё CSS к текстовым файлам прикрутим.
Внезапно, подсветка кода в редакторе это применение стилей к тексту. Ширина таба это тоже дополнительный стиль отображения, как например размер шрифта.
Внезапно, подсветка кода в редакторе это применение стилей к тексту.Хорошая аналогия.
Ширина таба это тоже дополнительный стиль отображения, как например размер шрифта.И так же, как считается дурным тоном менять размер шрифта в
:hover, также и не стоит менять размер таба без крайней на то необходимости в текстовых файлах.поставил две табуляции, а остальное догнал пробелами
Стоп-стоп-стоп, вот тут ложный посыл, а дальше уже из него все глупости и пошли. Проблема в вашем примере не в использовании табов, а в использовании пробелов. Смотрите, ничего не едет:
2 пробела на таб:
5 пробелов на таб:
9 пробелов на таб:
К сожалению, мало кто делает так же аккуратно.
Видел проект, где отступ первого уровня делался 4 пробелами, а отступ второго уровня — одним табом...
Ну это ведь проблемы не табов и не пробелов, а людей.
Нельзя обвинять людей в том, что они суп едят ложкой, а землю копают лопатой.
Я понимаю, что обезьяны всю жизнь только били палками окружающих, но люди из палок сделали инструменты и используют их не только так, как раньше. Я использую палку как рычаг и осуждаю вас за то, что вы бьете палками окружающих. Хоть оно исторически только так и было.
Но можно, если они суп едят лопатой, а копают — ложкой.
Тут нам как раз и предлагается копать ложкой.
Табы (как следует, собственно, из названия) предназначены для создания таблиц (тут и картинки приводили) — а «табы переменной, заранее неизвестной ширины» для этого, в общем, непригодны (за исключением, пожалуй, elastic tabstops — но вот как раз их-то мало кто поддерживает).
Но тот факт, что этот подход вступает вразрез с тем, как табы используются в миллионах уже существующих документов — уже достаточен для отказа от него.
Табы (как следует, собственно, из названия) предназначены для создания таблиц (тут и картинки приводили) — а «табы переменной, заранее неизвестной ширины» для этого, в общем, непригодны (за исключением, пожалуй, elastic tabstops — но вот как раз их-то мало кто поддерживает).
Но тот факт, что этот подход вступает вразрез с тем, как табы используются в миллионах уже существующих документов — уже достаточен для отказа от него.
Видел проект, где отступ первого уровня делался 4 пробелами, а отступ второго уровня — одним табом...То есть в этом проекте табы использовались по их прямому назначению — в чём проблема?
Собственно это — то, как почти все проекты в которых участвуют сотни и тысячи разработчиков устроены.
Вот вам gcc. А вот вам Linux — тут вообще написано просто и жёстко: There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Задолбали ужеэсперантисты любители резиновых табов. Просто секта какая-то.
Вот вам gcc. А вот вам Linux — тут вообще написано просто и жёстко: There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Задолбали уже
Совсем недавно вы написали:
Чтобы решить вопрос «какие отступы вам нравятся» и было придумано использовать табы для отступов. И это реально работает. Мне нравятся отступы размером в 4 пробела. Вам нравятся отступы в 8 пробелов (предположим, что вы поклонник Торвальдса и когда сказали, что код слишком быстро убегает вправо — это вы погорячились и забыли что говорил гуру против этого аргумента). Общий знаменатель для нас обоих — использовать табы для отсутпов. И вам будет приятно читать и дописывать этот код, и мне будет приятно делать то же саме. И Пете, который хочет отступы размером в 2 пробела. Всё что для этого нужно — это настроить в своём основном инструменте комфортный размер табов. Если где-нибудь на стороне вы увидите код с табами, размер которых вам не нравится — душевная травма от этого будет невелика. Вы знаете, что вы можете взять этот код, и не изменяя в нём ни символа — он в вашем основном софте покажется именно так, как вам нужно. И то маленькое неудобство от того, что вы где-нибудь в левой софтине случайно мельком увидели не такой размер таба не идёт ни в какое сравнение с печалью, когда вам нужно дорабатывать код, который использует по 2 пробела для отступов, а вам привычно 4 или вообще 8 (как Торвальдсу).
То есть пробелы — это постоянная боль при работе с кодом, если принятый в коде отступ не совпадает с вашим предпочитаемым. А он часто не совпадает. Мне не раз приходилось дорабатывать код с отступом в 2 пробела — и это была перманентная боль и ненависть. А ведь кто-то это писал, и наверняка он скажет, что ему 4 пробела — это как мне 8 пробелов. Слишком много. То что вы можете увидеть свой код где-нибудь мельком, где будет не такой размер отступов, как вам нравится — такая мелочь, по сравнению с этим. Тем более, что все свои инструменты вы сможете настроить, чтобы больше не огорчаться по этому поводу (и все адекватные инструменты имеют такую настройку). Даже в CSS добавили настройку размера таба. Просто потому что он не фиксирован. Он может быть любым. По умолчанию (в большинстве случаев в обычных редакторах, не предназначенных для кода) — как 8 пробелов, но это не обязательно.
То есть ваша претензия к тому, что если в редакторе по умолчанию таб 8 символов (кстати, в обсуждаемом Notepad++, если мне не изменяет память, по умолчанию 4), то при таких отступах код очень быстро уползает вправо. И тут же вы ссылаетесь на документ, который говорит:Моя технология работает при ЛЮБЫХ настройках, что я и показал.При настройках по умолчанию текст начинает очень быстро уползать за правую границу экрана.
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.То есть теперь уже отступы по 8 символов ок и код уже не убегает вправо слишком быстро? И вообще другие размеры отступов придумали еретики? Вы уж определитесь с аргументацией и не используйте аргументы, которые противоречат друг другу.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program.
Чтобы решить вопрос «какие отступы вам нравятся» и было придумано использовать табы для отступов. И это реально работает. Мне нравятся отступы размером в 4 пробела. Вам нравятся отступы в 8 пробелов (предположим, что вы поклонник Торвальдса и когда сказали, что код слишком быстро убегает вправо — это вы погорячились и забыли что говорил гуру против этого аргумента). Общий знаменатель для нас обоих — использовать табы для отсутпов. И вам будет приятно читать и дописывать этот код, и мне будет приятно делать то же саме. И Пете, который хочет отступы размером в 2 пробела. Всё что для этого нужно — это настроить в своём основном инструменте комфортный размер табов. Если где-нибудь на стороне вы увидите код с табами, размер которых вам не нравится — душевная травма от этого будет невелика. Вы знаете, что вы можете взять этот код, и не изменяя в нём ни символа — он в вашем основном софте покажется именно так, как вам нужно. И то маленькое неудобство от того, что вы где-нибудь в левой софтине случайно мельком увидели не такой размер таба не идёт ни в какое сравнение с печалью, когда вам нужно дорабатывать код, который использует по 2 пробела для отступов, а вам привычно 4 или вообще 8 (как Торвальдсу).
То есть пробелы — это постоянная боль при работе с кодом, если принятый в коде отступ не совпадает с вашим предпочитаемым. А он часто не совпадает. Мне не раз приходилось дорабатывать код с отступом в 2 пробела — и это была перманентная боль и ненависть. А ведь кто-то это писал, и наверняка он скажет, что ему 4 пробела — это как мне 8 пробелов. Слишком много. То что вы можете увидеть свой код где-нибудь мельком, где будет не такой размер отступов, как вам нравится — такая мелочь, по сравнению с этим. Тем более, что все свои инструменты вы сможете настроить, чтобы больше не огорчаться по этому поводу (и все адекватные инструменты имеют такую настройку). Даже в CSS добавили настройку размера таба. Просто потому что он не фиксирован. Он может быть любым. По умолчанию (в большинстве случаев в обычных редакторах, не предназначенных для кода) — как 8 пробелов, но это не обязательно.
То есть ваша претензия к тому, что если в редакторе по умолчанию таб 8 символов (кстати, в обсуждаемом Notepad++, если мне не изменяет память, по умолчанию 4), то при таких отступах код очень быстро уползает вправо.Моя претензия в том, что если делать отступы с помощью символа табуляции и не учитывать тот факт, что стандартный его размер — 8 символов, то текст быстро уползает вправо.
То есть теперь уже отступы по 8 символов ок и код уже не убегает вправо слишком быстро?Если код структурирован так, что у него отступы по 8 символов и при этом он не уползает вправо — то почему нет? Для меня не так важно — как конкретно размечен код, важно чтобы при стандартных настройках его можно было читать.
Чтобы решить вопрос «какие отступы вам нравятся» и было придумано использовать табы для отступов.Откуда вообще взялась эта проблема? Какая мне, в сущности, разница — отступы в 2, 4, или 8 символов вы используете? Я непривередлив. Для меня главное — чтобы текст был нормально читаем при стандартных настройках системы — то есть когда таб стопы расставлены через 8 символов. Но вот собственно только этому, простому и естественному, требованию — указанный подход и не удовлетворяет! Только если одновременно с использованием табуляции для отступов сами отступы не принимаются размером в 8 символов (как в ядре Linux'а) — с соответствующим форматированием кода. Но если вы уже приняли такие отступы — то зачем вам нужна гибкость с переменной шириной табов?
И то маленькое неудобство от того, что вы где-нибудь в левой софтине случайно мельком увидели не такой размер таба не идёт ни в какое сравнение с печалью, когда вам нужно дорабатывать код, который использует по 2 пробела для отступов, а вам привычно 4 или вообще 8 (как Торвальдсу).Вот не вижу вообще никакой печали от того, что в каком-то коде отступы в 2 символа, а в другом — 8 символов. А вот от того, что я не могу нормально работать с кодом при стандартных настройках — печаль таки вижу.
Мне не раз приходилось дорабатывать код с отступом в 2 пробела — и это была перманентная боль и ненависть.Отчего вдруг? Какая вообще разница — сколько там пробелов? На фоне всего остальное (названия переменных и общая структура кода) — это мелочи.
Тем более, что все свои инструменты вы сможете настроить, чтобы больше не огорчаться по этому поводу (и все адекватные инструменты имеют такую настройку).В том-то и дело, что не смогу. Я пользуюсь сейчас тремя системами ревью кода, несколькими программами для слияния файлов, да, в конце-концов могу иногда просто текст скрипта какого-нибудь распечатать с помощью «adb shell cat filename»! Это если не считать разных инструментов, с которым я сталкиваюсь раз в месяц. У меня нет ни времени, ни сил для настройки всего этого зоопарка. Потому единственное требования у меня простое и незатейливое: всё должно нормально выглядеть при стандартных настройках всех этих инструментов.
Но вот ровно этому требованию предложенный «гибкий» подход как раз и не удовлетворяет.
Даже в CSS добавили настройку размера таба.Заметьте — в CSS, не в GUI браузера!
Просто потому что он не фиксирован.Для текстовых файлов — фиксирован. 8 символов. Что там у вас в Word'е или QuarkXPress — меня мало волнует.
Для меня не так важно — как конкретно размечен код, важно чтобы при стандартных настройках его можно было читать.
И таки код с отступами на табах вы сможете нормально читать. Просто отступы будут 8 символов, как в коде ядра Linux. На современных размерах мониторов вообще не проблема даже если не ограничиваться тремя уровнями вложенности.
Откуда вообще взялась эта проблема? Какая мне, в сущности, разница — отступы в 2, 4, или 8 символов вы используете? Я непривередлив. Для меня главное — чтобы текст был нормально читаем при стандартных настройках системы — то есть когда таб стопы расставлены через 8 символов. Но вот собственно только этому, простому и естественному, требованию — указанный подход и не удовлетворяет!
Так забавно видеть «я непривередлив», и следом — очень привередливое требование :)
Вот не вижу вообще никакой печали от того, что в каком-то коде отступы в 2 символа, а в другом — 8 символов. А вот от того, что я не могу нормально работать с кодом при стандартных настройках — печаль таки вижу.
То что у вас табы отображаются не с таким размером, как у автора, никак не мешает вам работать с этим кодом на стандартных настройках. Код с отступами на табах будет выглядеть нормально с любым размером таба: хоть 2, хоть 8. И работать с ним сможет любой программист, независимо от того, какой размер таба ему удобен. Использовать пробелы для отступов — это своего кода эгоизм «мне так удобно, а вы привыкайте к моим отступам».
Отчего вдруг? Какая вообще разница — сколько там пробелов? На фоне всего остальное (названия переменных и общая структура кода) — это мелочи.
Не выдавайте субъективное за объективное. Меня вот гораздо меньше напрягают странные имена переменных, чем плохие отступы. (Я комфортно чувствую себя в ассемблере, где имена почти всех инструкций — это сокращения из пары-тройки символов.)
Для текстовых файлов — фиксирован. 8 символов. Что там у вас в Word'е или QuarkXPress — меня мало волнует.
Вы видите только то что хотите увидеть. Какой-то прям религиозный подход :) Я выше упомянул, что в обсуждаемом Notepad++ по умолчанию размер таба — 4 пробела. А это именно что редактор обычных текстовых файлов. И многие другие редакторы также имеют соответствующую настройку, именно потому, что размер таба не фиксирован — он настраиваем. И если в каком-то редакторе нет такой настройки (например, notepad.exe из стандартной поставки Windows) — то это проблема этого редактора. Впрочем, notepad.exe и \n не понимает, ему \r\n подавай. Тем не менее, \n без \r часто используется в текстовых файлах. Беда же! На самом деле нет.
На современных размерах мониторов вообще не проблема даже если не ограничиваться тремя уровнями вложенности.Разместите три копии кода для тройного слияния — и вы поймёте что даже «на современных размерах мониторов» таки «размер имеет значение»…
Использовать пробелы для отступов — это своего кода эгоизм «мне так удобно, а вы привыкайте к моим отступам».А все эти соглашения по тому куда расставлять скобочки и как называть переменные — это не эгоизм?
Меня вот гораздо меньше напрягают странные имена переменных, чем плохие отступы.И потому вы хотите тысячи (хотя, скорее, миллионы) разработчиков изменить их правила, передалеть используемые ими инстроументы и вообще совершить революцию ради вашего удобства. Это — не эгоизм?
Я выше упомянул, что в обсуждаемом Notepad++ по умолчанию размер таба — 4 пробела.И вот именно это — и является проблемой, как я уже говорил. Пока вы работает с кодом со стандарными табами — у вас нет проблем. Как только вы начинаете использовать разные варианты — у вас проблемы. И ратовать нужно не за «гибкие схемы», а за постепенный отказ от самодеятельности и переход на стандартный размер. Microsoft достаточно дров наломал со своими табами в 4 символа — незачем это продолжать.
вообще совершить революцию ради вашего удобства
Нет революции в использовании табов. Большинство разработчиков использует кнопку tab для вставки отступов. Просто в моду вошла автоматическая вставка пробелов вместо таба средствами IDE или блокнота. При этом важно заметить, что она идёт всё равно до табстопа, то есть имитирует поведение таба.
Это — не эгоизм?
Это попытка показать, что существует компромиссное решение, которое могло бы устраивать всех. Кроме крайних случаев, когда это не подходит по религиозным соображениям, конечно же.
И вот именно это — и является проблемой, как я уже говорил. Пока вы работает с кодом со стандарными табами — у вас нет проблем. Как только вы начинаете использовать разные варианты — у вас проблемы.
Переделать кучу уже существующих инструментов, где размер табов меняется — не представляется возможным. И если вы опираетесь на фиксированный размер таба — это и является проблемой. Потому что изменяемый размер таба — это уже давным давно данность, от которой вам никуда не деться.
Это попытка показать, что существует компромиссное решение, которое могло бы устраивать всех.А ещё мы могли бы использовать в качестве языка международного общения эсперанто вместо английского.
Переделать кучу уже существующих инструментов, где размер табов меняется — не представляется возможным.И не нужно. Если в них размер таба меняется — нужно выставить там 8 и всё.
Та же самая история, что и с UTF-8: нужно просто потихоньку отказаться от использования всего остального — и всё.
Потому что изменяемый размер таба — это уже давным давно данность, от которой вам никуда не деться.Ага. А кодировки — это ужас с которым нам придётся жить столетиями. Ага-ага.
Если в них размер таба меняется — нужно выставить там 8 и всё.
Почему 8? Хоть один разумный довод кроме «так было полвека назад». Серьёзно, этот аргумент выглядит так же, как «так написано в Библии». Да не важно как там было, важно как сейчас. Таб не имеет фиксированного размера. Он может быть любым. Смиритесь.
К слову, при просмотре текстовых файлов шрифт не обязан быть моноширным (вот только не надо говорить, что в полвека назад только такие и были). И в данном случае тот же notepad.exe (где таб только «стандартный» и нет настроек) выводит таб размером с 18 пробелов, если шрифт Times New Roman, и 14 пробелов, если шрифт — Arial. Нет и намёка на 8.
Хоть один разумный довод кроме «так было полвека назад».А вам нужен ещё какой-то довод? В IT индустрии (да и в любой другой, если копнуть) «ширина лошадиной задницы» определяет если не всё, то очень многое (если не читали байку — просветитесь). По той же самой причине мы на телефоне используем далеко не оптимальную QWERTY (и слегка более оптимальный ЙЦУКЕНГ).
Да не важно как там было, важно как сейчас.Он и сейчас полагается равным 8 символам в массе инструментов и массе самых разных проектов.
Таб не имеет фиксированного размера. Он может быть любым. Смиритесь.Извините, но… смириться придётся вам. Потому просто, что людей, рассчитывающих на табы фиксированной ширины банально больше — и они не будут всё на свете переделывать чтобы вам угодить.
Максимум, чего вы сможете добиться — отказа от использования табов вообще. Это — да, популярная опция и со временем становится всё популярнее.
Если введение настрийки «ширины таба» преследовало целью именно это — то да, можете праздновать победу, мы туда движемся уверенно.
Добиться того, чтобы люди подстраивались под «резиновые табы», вы не сможете, не стоит даже и пытаться.
К слову, при просмотре текстовых файлов шрифт не обязан быть моноширным (вот только не надо говорить, что в полвека назад только такие и были).Не полвека. Лет 10 назад народ пытался прикрутить к разнообразным IDE пропорциональные шрифты. Не прижилось. Опять-таки, потому что большинство писало программы с рассчётом на моноширинные шрифты и их не волновало — смогут ли на них смотреть любители пропорциональных…
Разместите три копии кода для тройного слияния — и вы поймёте что даже «на современных размерах мониторов» таки «размер имеет значение»…
Да, действительно, чё-то не помещается. Вот было бы клёво таб на время поменьше сделать, чтобы этот файл без горизонтальной прокрутки просматривать.
Вот было бы клёво таб на время поменьше сделать, чтобы этот файл без горизонтальной прокрутки просматривать.Но… Зачем? Ширина текста, который человек нормально может воспринимать — не так велика, это уже давным-давно ещё при разработке форматов для газет и журналов прощитывали. Достаточно подобрать размер шрифта, подходящее ограничение на ширину строки (80 символов или там 100) — и всё.
Стоп-стоп-стоп, вот тут ложный посылКакой, нафиг, «ложный посыл»? Табы — это способ выровнять текст на определённые вертикальные линии. Не больше, не меньше. Эти линии для каждого документа фиксированы. Если нужно попасть куда-то ещё — есть пробелы. В более сложных форматах, чем тестовый файлб есть возможность эти позиции переставить, в текстовом документе — такого способа нет. И всё.
Я, в частности, использую отступы в два символа (так мне удобнее и вообще — корпоративный стандарт) и табы в 8 симоволов (так как — стандартное значение для текстовых файлов, HTML и т.п.)
Ваша технология при стандартных настройках — не работает. Всё.
Эти линии для каждого документа фиксированы
Сначала сами придумали себе ненужные ограничения, а потом стараетесь ими аргументировать. Не надо так.
в текстовом документе — такого способа нет
А в любом вменяемом редакторе кода — есть. Если вы пишете в блокноте — это проблемы людей, которые с вами работают и это уже их дело переубедить вас или смириться с вашими тараканами.
Ваша технология при стандартных настройках — не работает. Всё.
Моя технология работает при ЛЮБЫХ настройках, что я и показал.
Сначала сами придумали себе ненужные ограничения, а потом стараетесь ими аргументировать.Добро пожаловать в мир IT-индустрии.
Не надо так.А как надо? Почему у нас все процессоры little endian при том, что big endian безопаснее? Ответ: потому что так исторически сложлось. То же самое и здесь.
А в любом вменяемом редакторе кода — есть.Кроме редакторов кода есть много других инструментов, которые могут работать с кодом. Всевозможные веб-сайты, системы контроля версий и прочее, прочее, прочее. Потому код должен нормально выглядеть, прежде всего, при использовании настроек по умолчанию.
Моя технология работает при ЛЮБЫХ настройках, что я и показал.При настройках по умолчанию текст начинает очень быстро уползать за правую границу экрана.
Добро пожаловать в мир IT-индустрии.
Нет, это лишь ваш воображаемый мир, который вы хотите представить, как всеобщий мир. К счастью я живу в ином мире.
А как надо? Почему у нас все процессоры little endian при том, что big endian безопаснее? Ответ: потому что так исторически сложлось. То же самое и здесь.
Если что-то исторически сложилось, то этому не обязательно теперь слепо следовать, особенно если легко можно не следовать. Если бы мы могли везде так легко менять «исторически сложилось» как можем это сделать с табами — наша жизнь была бы только лучше.
При настройках по умолчанию текст начинает очень быстро уползать за правую границу экрана.
1. Это не означает, что оно работает неправильно
2. Настройки по-умолчанию легко меняются на любые другие.
Если что-то исторически сложилось, то этому не обязательно теперь слепо следовать, особенно если легко можно не следовать.Легко можно не следовать — это поменять тысячи программ на миллионах компьютнеров? Нифига себе «легко».
Если бы мы могли везде так легко менять «исторически сложилось» как можем это сделать с табами — наша жизнь была бы только лучше.Проблема в том, что вы сильно недооцениваете сложность замены размера таба. У вас есть уютный мирок, где вы себе всё подстроили — и вы в нём живёте. А я общаюсь с кучей разных инструментов на разных платформах и менять в них всех понятие таба — «себе дороже». Особенно ради сомнительного выигрыша.
2. Настройки по-умолчанию легко меняются на любые другие.Это вам к эсперантистам. Это они рассказывают сказки, что если вдруг все перестанут использовать ужасный английский для мендународной переписки — так сразу всем щастя настанет. Не надо так. Ваш файл должен хороши читаться прижде всего с настройками по умолчанию. Чего большинство апологетов «резиновых табов» таки не достигают. Увы. Всё остальное — уже неважно.
1. Это не означает, что оно работает неправильноЭто обозначет что использовать ваш стиль — неудобно если вам небходимо работать с большой командой. А если вы не работаете с большой командой и пишите текст только «для себя» — то так ли важно какие там отступы?
Все команды, с которыми я работал прекрасно управлялись с табами. Пробовали работать с более профессиональными разработчиками? Ну чисто так, для разнообразия.
Опять глупость какая-то. Вы сегодня решили пойти на рекорд? Зачем менять код там, где он уже написан? Тем более уже написанный код есть и с табами, и с пробелами.
У таба нету размера, потому переоценивать тут нечего.
Легко можно не следовать — это поменять тысячи программ на миллионах компьютнеров?
Опять глупость какая-то. Вы сегодня решили пойти на рекорд? Зачем менять код там, где он уже написан? Тем более уже написанный код есть и с табами, и с пробелами.
Проблема в том, что вы сильно недооцениваете сложность замены размера таба
У таба нету размера, потому переоценивать тут нечего.
Пробовали работать с более профессиональными разработчиками?Как определяется профессионализм? Если по количеству пользователей — то речь идёт о разработчиках, продукцией которых пользуются миллиарды.
Ну чисто так, для разнообразия.А вы расскажите уж о проектах с числом разработчиков от тысячи и числом строк от 10 миллионов где используется ваша технология — тож для разнообразия. Вы ж говорите что это важно, когда разраработчики разные, то есть из много.
Зачем менять код там, где он уже написан?А вот ради этого: я открываю в редакторах, которыми пользуюсь, а там всё нормально настроено.
Мы очень рады за то, что вы открываете код только в редакторах, в которых «всё нормально настроено». А я открываю код не только редакторах, но и в системах контроля версий, в разнообразных web-инструментах, да, черт побери, мало ли где может оказаться мой код? В логах разнообразных, к примеру. В выдаче сообщений об ошибках и прочем.
И вы предлагаете вот это вот всё подстраивать под ваше «видение мира»? Спасибо, но… спасибо не надо.
У таба нету размера, потому переоценивать тут нечего.У таба есть размер. Иначе в нём бы не было никакого смысла вообще. В текстовых файлах это — 8 символов.
А что, есть стандарт который как-то регламентирует сколько знакомест должен взять на себя байт 0x09 при отображении в каком-либо ПО?
Зря тащите пережитки прошлого и несовершенство отдельного взятого ПО которое не позволяет вам выставить произвольный размер табуляции.
Это как если бы запрещали использовать юникод потому что какие-то недоредакторы его не поддерживают.
пЕАЪРЮ, ДЮБЮИРЕ ФХРЭ ДПСФМН!
Зря тащите пережитки прошлого и несовершенство отдельного взятого ПО которое не позволяет вам выставить произвольный размер табуляции.
Это как если бы запрещали использовать юникод потому что какие-то недоредакторы его не поддерживают.
пЕАЪРЮ, ДЮБЮИРЕ ФХРЭ ДПСФМН!
А что, есть стандарт который как-то регламентирует сколько знакомест должен взять на себя байт 0x09 при отображении в каком-либо ПО?Отдельного стандарта я не припомню, но как часть разных стандартов оно встречается. Вот тут, например, или здесь (таблица совместимости с браузерами). Да, там указывается и возможность его поменять, но это, как правило, опция. У текстовых файлов никаких CSS нету и, соответственно, как менять и где задавать tab-size — непонятно. А у питона это в спецификации языка прописано.
Это как если бы запрещали использовать юникод потому что какие-то недоредакторы его не поддерживают.Какую проблему решает переход на юникод — я понимаю. Какую проблему решает отказ от стандартного трактования табуляции как перехода к о чередной «позиции табуляции» выставленной через каждые 8 символов — нет.
Вреда от попыток изменить трактовку символа табуляции — куда больше, чем пользы. Хотите искать приключений на свою задницу — заведите символ в PUA — и трактуйте его как хотите.
пЕАЪРЮ, ДЮБЮИРЕ ФХРЭ ДПСФМН!Ага. Юникод нас спас от указания кодировок — вернём проблему?
Стало быть стандарта нет, тем более оправдывающего нужды такого размера в современных реалиях. Есть просто какие-то отдельно взятые нормы аля стили кодирования. Традиция тянущаяся со времён печатных машинок.
Так же как и CR+LF в винде просто традиция унаследованная от DOS/DEC, ранее тянущаяся тоже с печатных машинок.
А решает проблему удобства читаемости без переформатирования исходника, на разных устройствах я могу настроить более оптимальные отступы и не маяться с костылями. У меня включено отображение этих символов в редакторе и подменять отображение самообманываясь лично я не желаю, как и не желаю видеть пробелы вместо табуляции для отступов, попадать мимо границы отступа и хранить лишний мусор на диске.
Так же как и CR+LF в винде просто традиция унаследованная от DOS/DEC, ранее тянущаяся тоже с печатных машинок.
где задавать tab-size — непонятноОчевидно в настройках ПО. Любой адекватный текстовый редактор или IDE позволяет указать желаемый размер табуляции и все остальное ПО тоже должно это уметь, это же просто отображение и ничего более, настройка добавляется программистом очень просто и никаких проблем.
Какую проблему решает отказ от стандартного трактования табуляцииНо стандартного трактования же нет, есть просто традиционное о котором всерьёз не думали.
А решает проблему удобства читаемости без переформатирования исходника, на разных устройствах я могу настроить более оптимальные отступы и не маяться с костылями. У меня включено отображение этих символов в редакторе и подменять отображение самообманываясь лично я не желаю, как и не желаю видеть пробелы вместо табуляции для отступов, попадать мимо границы отступа и хранить лишний мусор на диске.
Любой адекватный текстовый редактор или IDE позволяет указать желаемый размер табуляции и все остальное ПО тоже должно это уметь, это же просто отображение и ничего более, настройка добавляется программистом очень просто и никаких проблем.А выбор кодировки — это тоже указание желаемого набора символов и ничего более, «настройка добавляется программистом очень просто и никаких проблем».
Но стандартного трактования же нет, есть просто традиционное о котором всерьёз не думали.POSIX — это таки стандарт, CSS — это проект стандарта, VT102 — тоже вполне себе задокументирован. Почему вы считаете что стандарт — это только что-то, принятое ISO? Если так подходить — то у нас вообще никаких стандартов нет, ни на ECMAScript, ни на C#, ни на Java'у.
У меня включено отображение этих символов в редакторе и подменять отображение самообманываясь лично я не желаю, как и не желаю видеть пробелы вместо табуляции для отступов, попадать мимо границы отступа и хранить лишний мусор на диске.Это ваш выбор. Если вы при всём при этом ещё и будете использовать символы табуляции размером 8 пробелов — то мне вообще будет пофигу. Но я использую символы табуляции для выравнивание текстов — и потому для меня важно, чтобы вы не устраивали чёрт знает что.
Вы тут сами подняли Юникод как «всеобщее благо» — а ведь он всего-навсего сделал так, чтобы символы с одними и теми же кодами не отображались по разному на разных машинах… так почему вы в отношении одного конкретного символа, с которым в 60е и 70е годы ни у кого не было никаких разночтений в трактовании сделать шаг назад и сделать так, чтобы он вёл себя по разному на разных системах? Где логика?
POSIX — это таки стандарт, CSS — это проект стандарта
Формата текстовых документов?
Если уже и считать все подряд «стандартом», в кодстайле Google написано, что выравнивание должно быть 2мя пробелами. Т.е. я могу смело утверждать, что таб — это 2 пробела, а не 8.
так почему вы в отношении одного конкретного символа, с которым в 60е и 70е годы ни у кого не было никаких разночтений в трактовании сделать шаг назад и сделать так, чтобы он вёл себя по разному на разных системах? Где логика?
Ну, многим, я уверен, абсолютно пофиг, на сколько таб там 8, 4 или 2. А от стандартизации мы получим сомнительную выгоду. Очень сомнительную. А все ваше нытье про то, что будет уезжать, ехать или еще что-то сомнительны. Если вас не устраивать текущее ПО, то почему вы его не меняете или не настраиваете? Времени нет? Лень? А холивар устроить не лень? Или проще стандартизировать таб(причем делать этого сами не хотите)?
Вашу проблему можно решить куда проще — использовать пробелы вместо табов и не так много. А если на выходе или входе табы — достаточно обработать исходник регулярным выражением, заменяя табы на N пробелов и наоборот. Уверен, что такой функционал уже даже кто-то делал. И проблемы с нестадартизированостью табов как-то исчезнут.
Если уже и считать все подряд «стандартом», в кодстайле Google написано, что выравнивание должно быть 2мя пробелами.Совершенно верно. И Google старается этого правила придерживаться. Даже в заимствованном и «переработанном» коде.
Т.е. я могу смело утверждать, что таб — это 2 пробела, а не 8.Вы идиот? Или просто играете роль идиота на Хабре? Возьмите это файл из кодбазы Google и посмотрите — как и для чего там используются табы. Отступы там стандартные, 2 пробела, как и написано в кодстайле.
А все ваше нытье про то, что будет уезжать, ехать или еще что-то сомнительны.Откройте вышеупомянутый файл у себя в редакторе — и посмотрите как он будет выглядеть. А потом сравните с тем, как он выглядит при стандартных настройках. Ну или исходники Notepad++ откройте.
Если вас не устраивать текущее ПО, то почему вы его не меняете или не настраиваете?Кто вам сказал, что меня не устораивает текущее ПО? Меня оно вполне устраивает. У меня нет файлов ненормально выглядящих при стандартных настройках (а если есть — то они правятся и всё становится снова в порядке).
Это вы хотите меня заставить менять ПО — только лишь ради того, чтобы я смог читать ваши замечательные файлы. Типичный случай, когда весь мир шагает не в ногу, а ты — в ногу. Не будет весь мир под вас перестраиваться, просто не будет, вот и всё.
Или проще стандартизировать таб(причем делать этого сами не хотите)?Проще работать с стандартными табами. Холивар решили устроить вы — в попытке заставить меня сломать то, что не сломано. Зачем это мне? А стандиртозовать как бы ничего не нужно: все известные мне инструменты либо обрабатывают стандартные табы, либо позволяют переключаться на работу с ними (и вот тут-то как раз исключений я не знаю: программ, в которые жёстко зашито, что таб имеет размер в 8 символов я-таки знаю, начиная с Python'а, а вот программ, которые используют по умолчанию что-то другое и не позволяют это менять — не видел).
Вашу проблему можно решить куда проще — использовать пробелы вместо табов и не так много.Угу. На том же сайте, на который вы ссылаетесь есть такое правило (правда для другого языка): Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.
Однако, заметьте, правила «если вы открыли файл с табами, то немедленно замените их все на пробелы» — нету. И табы в файлах вполне себе живут и здравствуют, как я показал выше.
А если на выходе или входе табы — достаточно обработать исходник регулярным выражением, заменяя табы на N пробелов и наоборот.Это не так-то просто: табы могут оказаться в исходнике не просто так. А в языках, в которых до исходника функции можно добраться (скажем тот же JavaScript) подобное действие может просто всё сломать.
Уверен, что такой функционал уже даже кто-то делал.Конечно. clang-format так умеет, к примеру. Но никто его не будет напускать на кодбазу в миллионы строк только для того, чтобы вас стало «приятнее на душе». Обычно он применяется только к изменённым строкам (смотреть в сторону git-clang-format).
Это вообще две ортогональные задачи: избавление от табов в исходниках и определения размера таба. Типичное решение нормальных людей просто и незатейливо: фетиша из этого не делать, табы использовать такими, какие они есть, но стараться, по возможности, не использовать их в коде.
Вы же предлагаете совершить непонятную революцию для того, чтобы людей, у которых и без неё есть чам заняться и у которых проблем нет они появились. Зачем оно им?
Вы идиот? Или просто играете роль идиота на Хабре?
А вот вы уже перешли на личности. И очень грубо и оскорбительно, кстати.
Извиняюсь, не сдержался. Просто думал, что уж кодстайл-то Google я хорошо знаю, благо они похожи (отступы — 2 символа что в C++, что в Java, табы — не используются ни здесь, ни там и так далее), но вы правы — перечитав JavaScript-стайл Google стайл-гайд и взглянув на него с точки зрения вашей религии можно действительно заподозрить, что в Google используется двухсимвольные табы… но голова-то на плечах есть? Кода, порождённого в соответствии с этим гайдом — в интеренете полно, можно же посмотреть и увидеть, что никакими табами там и не пахнет…
Вы идиот? Или просто играете роль идиота на Хабре? Возьмите это файл из кодбазы Google и посмотрите — как и для чего там используются табы.
Это всего лишь был сарказм, не ожидал, что вы примете его за чистую монету. Извиняюсь.
Я вообще к тому это сказал, что любую стороннюю спецификацию можно использовать для трактовки размера таба. Как вы сами сказали,
Отдельного стандарта я не припомню
и на этом тему «таб должен отображаться как 8 символов/пробелов» можно закрыть.
Это вы хотите меня заставить менять ПО — только лишь ради того, чтобы я смог читать ваши замечательные файлы. Типичный случай, когда весь мир шагает не в ногу, а ты — в ногу. Не будет весь мир под вас перестраиваться, просто не будет, вот и всё.
Типичное решение нормальных людей просто и незатейливо: фетиша из этого не делать
Может вам стоит перечитать перед добрыми 2/3 оставшегося ответа? Я же написал:
Ну, многим, я уверен, абсолютно пофиг, на сколько таб там 8, 4 или 2
Т.е. лично я ваш код перестраивать под себя не буду. И код на миллион строк тоже. А что делать с моим кодом(если он вам конечно попадется xD) решать вам.
На этом можно закончить, но вот вам еще забавный момент:
Вы же предлагаете совершить непонятную революцию для того, чтобы людей, у которых и без неё есть чам заняться и у которых проблем нет они появились. Зачем оно им?
А я написал:
А от стандартизации мы получим сомнительную выгоду. Очень сомнительную.
Опять-таки я только против какой-то революции таба на 8 проблемов.
и на этом тему «таб должен отображаться как 8 символов/пробелов» можно закрыть.Почему вдруг? Потому что стандарты не озаглавленные «Ширина таба, как она есть» «некошерны»?
Опять-таки я только против какой-то революции таба на 8 проблемов.Какая «революция»? О чём вы? Таб имел ширину в 8 символов в 70е, таб имер ширину 8 симполов в 80е, только в 90е Microsoft с сотоварищами начал «мутить воду». Ну так кончится Microsoft — кончится и эта истерия. Нужно только подождать. VAX'ы продержались 23 года, Windows оказалась покрепче, но тоже уже видно что рано или поздно это безумие кончится. Всему своё время.
Почему вдруг? Потому что стандарты не озаглавленные «Ширина таба, как она есть» «некошерны»?
Нет. Потому, что вы утверждаете, что таб должен отображаться как 8 пробелов в текстовом формате. Linux и Python и все остальные примеры — всего лишь отдельные случаи, которые регулируют соответствующие сферы. Ни о каком общем правиле не может идти речь.
Допускаю, какие-то неписаные правила того, что таб равен 8ми пробелам, вообщем то, существуют. Однако это как best practise: хочешь — используй, а хочешь — нет. Отстаивать с пеной у рта не стоит.
Microsoft с сотоварищами начал «мутить воду»
Гнать на Microsoft бочку про неканонические табы… Интересно, откуда. Если мы именно о символе табуляции — то с ним у Microsoft'овского Блокнота все по канону. А если брать в расчет VS — а там замена на пробелы, если не ошибаюсь — тогда кодстайл Google очень даже аргумент
А как надо? Почему у нас все процессоры little endian при том, что big endian безопаснее? Ответ: потому что так исторически сложлось. То же самое и здесь.
Ворвусь в холивар про табы vs пробелы с замечанием, что little endian таки безопаснее, в нём при неявном кастинге указателя на другой (меньший) тип не нужно менять значение указателя. А это гораздо безопаснее чем иметь вероятность считать старшую половину слова при кастинге например uint32->uint16. Даже большинство ARMов на Linux/Android уже в LE режиме, несмотря на допзатраты по разворачиванию заголовков в TCP/IP.
Ворвусь в холивар про табы vs пробелы с замечанием, что little endian таки безопаснее, в нём при неявном кастинге указателя на другой (меньший) тип не нужно менять значение указателя…и именно это делает его более опасным.
А это гораздо безопаснее чем иметь вероятность считать старшую половину слова при кастинге например uint32->uint16.s/безопаснее/опаснее/
Что происходит на Big Endian, если вы перепутали размеры? Правильно: программа получает в качестве входных данных мусор, падает, программист ругается матом, чинит проблему — и на этом всё кончается.
Что происходит на Little Endian, если вы перепутали размеры? Тесты проходят, программа сдана заказчику, exploit написан, весь мир на ушах.
Так какой мир более безопасен? Тот в котором Джо (…или Иван… или Ляо) потратил два лишних часа на отладку программы? Или тот, в котором необнаруженная ошибка просочилась на миллиарды компьютеров и привела к потерям измеряющимся в десятках и сотнях миллионах долларов?
Даже большинство ARMов на Linux/Android уже в LE режиме, несмотря на допзатраты по разворачиванию заголовков в TCP/IP.И это очень хорошо показывает во что IT-индустрия ценит безопасность. Ни во что. Совместимость важнее — а они с безопасностью очень частно «на ножах». Вот и вы их спутали, хотя казлось бы — всё очевидно.
Что происходит на Big Endian, если вы перепутали размеры? Правильно: программа получает в качестве входных данных мусор, падает, программист ругается матом, чинит проблему — и на этом всё кончается.
Неправильно, по двум причинам:
1. Компилятор C при явном приведении типа uint32->uint16 на BE правильно обрежет данные, он достаточно умный в этом плане. Ну а если программист сам читает данные побайтно и/или вручную кастует указатели не понимая различия LE/BE, то он сам себе буратино и проблем огребёт независимо от платформы.
2. Если бы все ветки кода и варианты его использования попадали в test coverage, то PVS Studio, в блоге которого мы сидим, был бы не нужен, не так ли? Граничных условий море и я не видел проектов, где хотя бы бОльшая часть покрывается тестами. Так что в общем случае, тесты пройдут и ничего не будет заметно, пока не выстрелит та самая ветка кода.
Что происходит на Little Endian, если вы перепутали размеры? Тесты проходят, программа сдана заказчику, exploit написан, весь мир на ушах.
До переполнения типа не происходит ничего, в остальных случаях происходит классический случай переполнения типа, что мешает переполнить переменную типа uint16/uint32 и получить то же самое поведение? Эта проблема не имеет отношения к endianness.
Вот и вы их спутали, хотя казлось бы — всё очевидно.
Совершенно неочевидно, особенно про то как связан buffer overflow в EternalBlue с различиями в BE/LE, поделитесь деталями, если не секрет. При обрезании индекса буфера на little endian мы можем получить только buffer underflow.
Компилятор C при явном приведении типа uint32->uint16 на BE правильно обрежет данные, он достаточно умный в этом плане.При работе с регистрами разницы между BigEndian и LittleEndian нет вообще. Она появляется при обращении в память.
Ну а если программист сам читает данные побайтно и/или вручную кастует указатели не понимая различия LE/BE, то он сам себе буратино и проблем огребёт независимо от платформы.Правда — вот только на BE он «огребёт себе проблем» практически моментально и будет вынужден проблемы как-то чинить, а на LE — они доживут не только до релиза, но и, скорее всего, до момента, когда софт будет использовать на миллиардах компьютеров по всему миру.
Если бы все ветки кода и варианты его использования попадали в test coverage, то PVS Studio, в блоге которого мы сидим, был бы не нужен, не так ли?Правда ваша — в коде, который вызывается редко (скажем обработчик ошибок, ага) — проблема может сидеть сколь угодно долго. Так что PVS-Studio без работы не останется. Однако шансов выжить у ошибки, подобной той, которую использовал WannaCry на BE было бы очень мало. Даже если бы тесты этот код не покрывали — скорее всего он бы у пользователей «выстрелил» и они багрепорты начали бы слать.
Я не говорю о том, что мир LE — ужасен, а мир BE — абсолютно безопасен. Это не так. Но то, что мир BE безопаснее, так как ошибки обнаруживаются раньше — это однозначно.
До переполнения типа не происходит ничего, в остальных случаях происходит классический случай переполнения типа, что мешает переполнить переменную типа uint16/uint32 и получить то же самое поведение?А если в код посмотреть вместо того, чтобы исходить из предположения о том, что вы всё знаете и так? Я вам даже этот кусочек могу прям сюда скопировать:
In vulnerable SrvOs2FeaListSizeToNt() function, there is a important change from WinNT4 (to fix OOB read) in for loop.Как вы думаете — долго бы программа прожила на BE-системе если бы к переменной типа DWORD лазили бы через указатель на WORD? А на LE-системе — она дожила до всемирной эпидемии.
The psuedo code is here.if (nextFea > lastFeaStartLocation) { // this code is for shrinking FeaList->cbList because last fea is invalid. // FeaList->cbList is DWORD but it is cast to WORD. *(WORD *)FeaList = (BYTE*)fea - (BYTE*)FeaList; return size; }
При обрезании индекса буфера на little endian мы можем получить только buffer underflow.Только если мы правильно его пишем и читаем. В противном случае мы легко можем прочитать младший байт от 0x100, интерпретировать его как нуль и разрешить буферу расти дальше, например.
Совершенно неочевидно, особенно про то как связан buffer overflow в EternalBlue с различиями в BE/LEbuffer overflow там случился, если вы почитаете детали, из-за того, что один и тот же указатель интерптетировали то как указатель на слово, то как указатель на байт, а в памяти там, на самом деле, вообще двойное слово лежало. И всё это — работало до поры до времени, пока не придумали как через это дело систему взломать. Попытка устроить подобную же «гремучую смесь» на BE-системе привела бы к тому что при первом же попадании туда чего-то, отличного от нуля, вся конструкция бы немедленно сломалась и её пришлось бы чинить, так что до никакиго buffer overflow код бы просто не дожил.
При работе с регистрами разницы между BigEndian и LittleEndian нет вообще. Она появляется при обращении в память.
Регистры тут совершенно ни при чем, при присвоении переменных по значению компилятор делает всё работу правильно по приведению типа.
Я не говорю о том, что мир LE — ужасен, а мир BE — абсолютно безопасен. Это не так. Но то, что мир BE безопаснее, так как ошибки обнаруживаются раньше — это однозначно.
Вот это утверждение для меня неоднозначно, есть статистика на эту тему? Еще один пример кривой игры с указателями не статистика, как я и говорил в своем комментарии, такие кодописатели сами себе буратины, огребут проблем независимо от BE или LE.
Как вы думаете — долго бы программа прожила на BE-системе если бы к переменной типа DWORD лазили бы через указатель на WORD? А на LE-системе — она дожила до всемирной эпидемии.
Да, долго. На BE платформах так же лазят к переменным типа DWORD через указатели на WORD, только по немного другим смещениям, не находите? Если бы Windows был только под BE, то приведённый вами код добили бы похожими хаками до рабочего состояния именно на этой платформе. При попытке собрать код под LE, оно бы предсказуемо рассыпалось.
вся конструкция бы немедленно сломалась и её пришлось бы чинить
У них именно всё сломалось (заметьте, на LE платформе, а не на BE), а программист починил «как смог», смотрите их описание:
there is a important change from WinNT4 (to fix OOB read)
Почему вы уверены, что когда ломается код на BE платформе, его внезапно починят правильно а не напихают подобных кривых хаков с выборочной загрузкой байтов из памяти?
На BE платформах так же лазят к переменным типа DWORD через указатели на WORD, только по немного другим смещениям, не находите?Не нахожу. Наиболее популярное смещение (на любой платформе) — это нуль. То есть указатель прямо указывает на переменную. На LE попытка использовать этот указатель с неправильным типом может работать довольно долго (пока кто-нибудь exploit не напишет). На BE практически любая попытка исполнить подобный код приводит к катастрофе, разбирательствам и, соответственно, исправлению программы.
Если бы Windows был только под BE, то приведённый вами код добили бы похожими хаками до рабочего состояния именно на этой платформе.Там не было хаков. Там было банальное рассогласование типов. Так вот на BE — подобная проблема обнаруживается почти сразу, а на LE — живёт годами, пока не «выстрелит».
Почему вы уверены, что когда ломается код на BE платформе, его внезапно починят правильно а не напихают подобных кривых хаков с выборочной загрузкой байтов из памяти?Потому что для получения проблемы вам нужно сделать не одну ошибку (грубо говоря перепутать
WORD PTR [%EAX] и DWORD PTR [%EAX]), а две (нужно будет умудриться случайно превратить DWORD PTR [%EAX] в WORD PTR [%EAX+2]) — что, согласитесь, сделать гораздо сложнее.То же самое с OOB: на LE вы можете взять — и просто читать два байта вместо четырёх, чтобы не вылазить за границы массива, а на BE — не можете, нужных вам байтов вы в этом случае не прочитаете.
Можно себе представить альтернативный мир, где указатели указывают не на первый байт многобайтового целого, а на последний и строки растут в сторону уменьшения адресов, а не увеличения — там LE будет безопаснее BE. Но в нашем мире этот подход, как бы, не прижился, указатели указывают на начало целого, а строки расширяются «вверх», а не «вниз»…
Кстати в этом «альтернативном» мире как раз BE обладал бы «ценным» свойством, которое вы рекламируете — и именно поэтому он был бы небезопасным.
Не нахожу. Наиболее популярное смещение (на любой платформе) — это нуль
… потому что вы привыкли приводить типы указателей на LE платформе? Замечательно, особенно если вы пропускаете такое в ваш код.
На BE практически любая попытка исполнить подобный код приводит к катастрофе, разбирательствам и, соответственно, исправлению программы.
Как я уже сказал, особенно замечательно, если этот код поселится в ветке, которая не покрывается вашими тестами (нет, не обработчик ошибок, а функциональность при определённой комбинации фич). +10 к надежности. И еще, вы уверены что любая попытка исполнить подобный код приведёт к крашу а не к потенциальному эксплоиту?
Там не было хаков. Там было банальное рассогласование типов. Так вот на BE — подобная проблема обнаруживается почти сразу, а на LE — живёт годами, пока не «выстрелит».
Опять же, повторюсь, если вы считаете «не хаками» приведение типов указателей, которое разваливается при сборке на платформе с другой endianness, то мне здесь добавить нечего.
… потому что вы привыкли приводить типы указателей на LE платформе?Нет — потому что подобное происходит автоматически при ошибке в описании типа и использовании «свободных» указателей, которых в типичной программе больше, чем структур. Они возникают при передаче параметров по значению (соответствено — и при возврате их из функции), при захвате одного параметра лямбдой (а тут, также, один — гораздо популярнее любых других значений… кроме нуля, пожалуй) и в куче других мест.
И еще, вы уверены что любая попытка исполнить подобный код приведёт к крашу а не к потенциальному эксплоиту?Почти любая. Вы «забираете» из памяти «старшую» половину числа и интерпретируете её как если бы это было всё число. Иногда — это может сработать (для чисел, которые состоят из одинаковых половин). Но на практике — это случается гораздо реже, чем «маленькие» числа, когда всё отрабатывает «на ура» в LE.
Как я уже сказал, особенно замечательно, если этот код поселится в ветке, которая не покрывается вашими тестами (нет, не обработчик ошибок, а функциональность при определённой комбинации фич). +10 к надежности.А с безопасностью часто так.
Опять же, повторюсь, если вы считаете «не хаками» приведение типов указателей, которое разваливается при сборке на платформе с другой endianness, то мне здесь добавить нечего.А вы — считате? Вот как видите
void* — и сразу верёвку и мыло готовите? Да чёрт с ним, c void*, рассмотрите какую-нибудь функцию подобную ReadFile и подумайте что будет если в один прекрасный момент вы решите перейти от 4х-байтовых длин файлов к 8-байтовым — а одну из библиотек забудете пересобрать. Думаете так никогда не бывает?Если вы немножко подумаете над тем, как устроены типичные API — то увидите, что там масса мест, где вы можете обратиться к переменной через указатель «не того» типа. И почти во всех этих местах программа на LE-системе будет какое-то время работать, а на BE-системе — упадёт почти сразу. Может ли быть обратное? Да, разумеется — вот только все примеры будут черезвычайно странными и вычурно выглядящими, не похожими и близко на простую ошибку при использовании pthread_create или чего-нибудь подобного.
Статистика GitHub говорит что пробелы гораздо популярнее
Это ложное утверждение
На всякий случай сразу кину пруф. Оригинальная статья — лживая манипуляция, не имеющая ничего общего с реальностью. Я описывал там в комментариях, что большинство проектов с табами они записали в «пробельные» из-за кода, составленного с ошибкой… Возможно, ошибка допущенна специально — она слишком глупая и очевидная.
Конечно же табы, конвертирующиеся в пробелы!
Я всегда включаю опцию "Отображать пробельные символы" во всех редакторах и придерживаюсь стиля проекта. Поэтому у меня нет проблем :)
Отступ в коде 4 пробела. Отступ в коде. Отступ. Среди всех символов кода мы выделяем отдельную сущность. Логично использовать для нее отдельный символ, а не заменять другими, всегда подразумевая что N пробелов это на самом деле не N пробелов, а один отступ, причем только в начале строки.
Логично использовать для нее отдельный символ, а не заменять другими, всегда подразумевая что N пробелов это на самом деле не N пробелов, а один отступ, причем только в начале строки.Логично. Нелогично брать символ с уже существующей семантикой и пытаться эту семантику менять для того, чтобы использовать его под эту вашу «сущность». Хотите сделать спецсимол для отступов — да ради бога, в PUA достаточно места. Зачем табы-то уродовать?
А вот кстати для табов с "обычным" назначением (для разметки таблиц в текстовых файлах) было бы неплохо сделать несколько новых табов шириной 8, 16, 24 пробела. Раньше-то ладно, однобайтовые кодировки, символов мало, форматов текста мало, а сейчас-то кто таблицы текстом размечает. Но если уж надо, то лучше чтоб таблица не ехала при добавлении 9-го символа в текст ячейки.
"Сапожник без сапог". Делают редактор, в котором есть функция замены табов на пробелы (и наоборот) во всём документе, а также замена вставки табуляции пробелами, при этом стиль своего собственного кода поправить не могут. Забавно.
Врядли они код пишут в самом notepad++.
Для начала — это просто неудобно.
Да к тому же сам npp не для того сделан.
Для начала — это просто неудобно.
Да к тому же сам npp не для того сделан.
Я не приверженец идеи писать код не в IDE. Просто наблюдение и мне это показалось забавным.
Да к тому же сам npp не для того сделан.
И всё же они позиционируют его как "source code editor" (так на сайте написано :))
IDE у разработчиков тоже могут быть настроены по разному.
в результате слияния pull request-ов от разных разработчиком — табы/пробелы перемешиваются.
Тут 2 варианта
* Вешать хуки на коммиты и заставлять править стиль руками.
* Использовать автоматический форматер типа http://astyle.sourceforge.net/ и периодически им причесывать код.
я уже много лет использую второй вариант — удобно
в результате слияния pull request-ов от разных разработчиком — табы/пробелы перемешиваются.
Тут 2 варианта
* Вешать хуки на коммиты и заставлять править стиль руками.
* Использовать автоматический форматер типа http://astyle.sourceforge.net/ и периодически им причесывать код.
я уже много лет использую второй вариант — удобно
> Использовать автоматический форматер
Блин, спасибо вам за идею, вечно мучался от своей и чужой лени в конфигах nginx'а, прочитал про автоматический форматер и быстро нагуглил готовый https://github.com/1connect/nginx-config-formatter от которого мои конфиги шустро пришли в нормальный вид.
Комменты на хабре всегда полезней самой статьи.
Блин, спасибо вам за идею, вечно мучался от своей и чужой лени в конфигах nginx'а, прочитал про автоматический форматер и быстро нагуглил готовый https://github.com/1connect/nginx-config-formatter от которого мои конфиги шустро пришли в нормальный вид.
Комменты на хабре всегда полезней самой статьи.
Мы используем http://uncrustify.sourceforge.net/
Действительно, есть люди, которые просто не способны соблюдать code style.
UFO just landed and posted this here
И всё же они позиционируют его как «source code editor» (так на сайте написано :))
Ну, для скриптовых/функциональных языков нормально подходит. В отличии от того же Сублайма, npp не стоит 70$ =)
Но там, где нужен нормальный дебаг/стак-трейс и прочие фишки IDE – конечно же, npp уступает.
может им приходится работать в другом редакторе, в котором нет такой функции:)
Мне интересно, а linux-проект из VS2017 можно проверить? Вообще, меня интересует проверка кросс-компиляторного проекта, но и такой вариант был бы не плох. Я пишу для embedded устройств на linux и я бы не против потестить анализатор.
Мы вышли на такой уровень, что проверяется всё, что компилируется.
Если есть стандартный проектный файл для VIsual Studio 2010-2017 и хотя бы компиляция проходит успешно (линковка не обязательна), то можно.
Но предположу, что Вам проще сразу воспользоваться PVS-Studio для Linux. Работа с кросс-компиляторами описана в разделе "Быстрый старт/Если вы используете кросс-компиляторы".
Для тестирования Вы можете обратиться в поддержку для получения временного ключа. Смотрите также "Как использовать PVS-Studio бесплатно".
а linux-проект из VS2017 можно проверить?
Если есть стандартный проектный файл для VIsual Studio 2010-2017 и хотя бы компиляция проходит успешно (линковка не обязательна), то можно.
Но предположу, что Вам проще сразу воспользоваться PVS-Studio для Linux. Работа с кросс-компиляторами описана в разделе "Быстрый старт/Если вы используете кросс-компиляторы".
Для тестирования Вы можете обратиться в поддержку для получения временного ключа. Смотрите также "Как использовать PVS-Studio бесплатно".
Настал момент, когда мы приходим в embedded-мир. Состоялся релиз PVS-Studio 6.22:
Предлагаю желающим попробовать новую версию PVS-Studio.
- Добавлена поддержка проверки проектов, использующих компиляторы Keil MDK ARM Compiler 5 и ARM Compiler 6.
- Добавлена поддержка проверки проектов, использующих компилятор IAR C/C++ Compiler for ARM.
Предлагаю желающим попробовать новую версию PVS-Studio.
ReactOS когда проверите?
Проверка ReactOS (сентябрь 2011), вторая проверка (апрель 2013)
Есть много поводов проверить этот проект, но в следующем году можно сделать аналогичную «5 лет спустя...». Посмотрим. Наверняка в названии будет ещё что-нибудь про поиск уязвимостей.
как они могут править свой код если пишут его в другом редакторе, который без таких возможностей как notepad++, почему бы не писать в нем же? так они ж его и пишут :) замкнутый круг. Если серьезно, то хорошая программа, ошибки есть, есть куда улучшить, но по сути и с ними одни из лучших на мой взгляд.
Вот зачем здесь эта проверка? Согласно современному стандарту C++, оператор new бросает исключение при нехватке памяти, а не возвращает nullptr.
Не обязательно
Called by the non-throwing non-array new-expressions. The standard library implementation calls the version (1) and returns a null pointer on failure instead of propagating the exception.
Взял отсюда.
Ну так здесь не nothrow оператор, да и код бы выглядел иначе, если явно указать. Не просто так же я написал:
Эта функция зовётся при замене всех символов табуляции на пробелы во всём документе. Взяв большой текстовый документ, я убедился, что нехватка памяти в этом месте действительно приводит к краху программы.
Тема табов и пробелов давненько существует, поэтому не сложно найти хорошую заметку с обзором всех плюсов и минусов. Но я почему-то никогда не видел, чтобы шутили про пробелы, только про табы.
В коде Notepad++ найдено несколько проблем с перегрузкой функций.
Override — это все-таки «переопределение», а не «перегрузка», которая overload.
Sign up to leave a comment.
Notepad++: проверка кода пять лет спустя