Комментарии 21
Возможно, в будущем мы придём к тому, от чего когда-то ушли: все исходники строго в ASCII. Лично я этому буду только рад, потому что с детства привык вместо литералов пользоваться ресурсами. Что даёт не только +10 к защите (от хакеров), но и +5 к локализуемости и +3 к пруфридингу/редактированию. К практике называть переменные 🍄 и 🐰 я тоже отношусь не очень хорошо: как бы, детский сад давно позади, пора уже выучить буковки.
Непонятно, правда, что делать с разметкой. Простые англоязычные лендинги я и так делаю в ASCII с энтитизацией всяких тире и копирайтов. Но вот энтитизировать русский текст (а мы так когда-то и жили, честно-честно!) мне больше не хочется. Помогло бы отделение структуры документа от текстового наполнения (это само по себе давно напрашивается), Юникод можно было бы разрешить строго для контентной части. Опять же, вынос текста за пределы структуры документа улучшил бы локализуемость и редактуру.
P.S. Да, и главное: больше никаких злобных споров о том, кто отломил BOM при коммите! Это бывает чаще, чем вы думаете (FAR, IDE, черепаха, консоль — за всем этим зоопарком не уследишь).
Непонятно, правда, что делать с разметкой.
Разметка должна быть в отдельном файле-шаблоне. Если какие-то языки мешают код и разметку - это очень большой косяк в дизайне языка.
Код это понятно, но разметку саму разбивать и разбивать.
Исторически мы имеем тренд в виде отпочкования от структуры (вложенных друг в друга элементов) разных вещей. Причём, отпочковываются они в виде DSL'ей. Сначала отпочковалась манипуляция этой структурой (JS до того, как он развился в ЯП общего назначения). Затем стилизация (CSS) и адресация (тот анонимный язык, на котором пишут селекторы, я его называю S[elector]L[anguage]).
Так что, я думаю, мы следовали бы курсу предков, отделив от структуры ещё и контент. Это можно сделать, развив нынешнее CSS-свойство content
до полноценного языка (какого-нибудь CL). Привязывать контент к элементам можно было бы как в CSS — на основе селекторов, а нынешнюю схему с текстом внутри тегов объявить инлайновой формой. Ну и затем ограничить использование Юникода в инлайновой форме, чтобы из контентной секции нельзя было порождать скрипты при помощи трюков типа BiDi (во внешних .cl-файлах пользуйся Юникодом сколько влезет, он там ничему не навредит).
Это не только увеличило бы безопасность, но и:
Можно было бы прозрачно делать локализации, указывая культуру в расширении файла (представьте себе набор файлов
index.html
,index.ru-ru.cl
,index.en-us.cl
и т.д.);Разметка, не замусоренная контентом, стала бы очень наглядной;
От структурных элементов отделились бы оформительские, типа
<b>
и<i>
, и тоже перестали бы замусоривать разметку (разумеется, оформительские элементы можно было бы использовать и как структурные, а вот наоборот, т.е.<script>
из контентных файлов — нет);Можно было бы наконец поженить markdown и HTML, сделав генерацию оформительских элементов типа
<b>
и<i>
из** **
и* *
.
Учитывая, что Комитет (W3C) даже очень полезные вещи (например, сокращения #
и .
для атрибутов id
/class
) обычно прокатывал на закатывающейся губе, ждать этих прекрасных изменений можно бы целую вечность. Но, к счастью или к несчастью, теперь у нас в IT безопасность вышла на первое место, авось и сделают. Хотя наверняка самым уродливым способом (как они сделали с document.querySelector
при наличии прекрасного $
).
Возможно, в будущем мы придём к тому, от чего когда-то ушли: все исходники строго в ASCII
С одной стороны да, с другой стороны как быть тем у кого не-ascii алфавиты? Как впендюривать лицензии в заголовки каким-нибудь французам, у которых есть две разных e с акутом, грависом и циркумфлексом. Тем же вопросом задаются норски с ихими æøå, фины с åäö и прочие северяне с собственными алфавитами, доставшихся от германских предков. Греки, арабы, китайцы, японцы и ещё половина азии - тоже хотят комментарии. У них конечно есть собственные альтернативы, как в СССР был KOI8, но многие помнят какие это проблемы создавало и как ради избавления от них все дружно стали пересеаживаться на utf. Так что не эмодзи едины.
Как впендюривать лицензии в заголовки каким-нибудь французам
Вынести лицензию в файл LICENSE? (Это, практически, стандарт).
Греки, арабы, китайцы, японцы и ещё половина азии - тоже хотят комментарии.
О, я такое видел. Открываешь файл, а там всюду замечательные комментарии на японском. Потому что компания японская, а благородные самураи не будут унижаться до гайджьинской латиницы в комментариях. Что могу сказать? Лучше бы такое видеть поменьше или, хотя бы, не на ночь.
Вынести лицензию в файл LICENSE? (Это, практически, стандарт).
Вы никогда не задумывались почему огромное количество опенсорса использует именно комментарий, а не отдельный файл. Во-первых, таким образом проще доказать, что кто-то сделал грязь, просто выпилив свободную лицензию, а во вторых один файл всегда лучше чем два и соседний файл предполагает, что нужно где-то держать эту папочку с лицензиями когда подключаешь очередную библиотеку. И какой-нибудь плюсовый код будет распространяться в вашем варианте не как header only, а header + license.
Какая-то слишком специальная ситуация, а обсуждать её предлагается как типовую.
Начну с того, что я ВООБЩЕ не видел лицензии не на английском языке. Но я напряг свою фантазию и представил, что кому-то может понадобиться не просто лицензия на французском латиницей, но ещё и с диакритикой (без неё она юридическую силу потеряет?). Думается мне, в этом крайне редком случае вполне достаточно будет в плюсовом хедере написать, кто автор и указать, что текст лицензии лежит в соседнем файле и обязан к распространению. А если это не поможет, давайте признаем, что мы просто имеем дело со свиньёй, которая плевать хотела на все лицензии.
Кроме того, никто и ничто не мешает включить в текст URL с лицензией хоть на папуасском, если это так принципиально.
Вообще, открыв хедер и увидев там вверху шапку лицензии на французском, китайском, японском, немецком или ещё каком-нибудь языке, я бы ОЧЕНЬ удивился и всерьёз задумался об адекватности автора. Для русского я бы сделал исключение, но это начиная с нынешнего года и чисто из-за геополитики.
Во многих лицензиях явным образом указывается имя держателя прав "Copyright (c) <year> <copyright holders> "
без неё она юридическую силу потеряет?
В русском языке Наталья и Наталия, Данил, Даниил и Данила - всё разные имена и кошмар бухгалтеров, например, так что подозреваю, что разница между Björn Járnsíða и Bjørn Járnsída вполне может быть значимой при доказательстве как минимум в какой-нибудь Исландии и Норвегии, в чьём алфавите до сих пор сохранились ð, þ (это не р), æ и ø соответственно. Локализованные лицензии видел только в установщиках, но речь явно не за эту ситуацию, а за ту, в которой вы взяли какой-то чужой код. Можно ещё почитать дополнения к лицензиям о том как их применять к своей работе: Apache 2.0, GPL-3.0 и иже с ним.
Рассмотрим пример, как отображается символ
0x200B
(zero width space)
А почему интерпретатор не падает с ошибкой, дойдя до этого символа? Полагаю, тут не в редакторе проблема.
которые заставляют компилятор читать исходный код в другом направлении либо вызывать совсем другие функции
А почему компилятор их не игнорирует или не падает с ошибкой при их появлении?
Newfags can't triforce. Проблеме тыща лет уже...
Строки должны лежать в ленгпаке (если есть) или быть на английском (ASCII, если нет ленгпака), каменты и код - быть на английском (тоже ASCII), а смузихлебы, которые не могут кодить без смайликов и тибетского языка, должны ссылаться в 1С программирование навсегда. И тогда можно сразу после чтения файла убирать из него все не-ASCII символы...
которые не могут кодить без смайликов и тибетского языка
Я не зря привел пример с символом доктора. Он у нас используется на сайте. То есть это не как часть кода или комментария в коде, а как то, что должны видеть конечные пользователи.
Если компилятор будет разрешать юникод только в комментариях то проблема рассосётся сама собой.
если грамматика языка позволяет любую дребедень использовать в именах объектов, функицй, переменных и в прочих конструкциях, то дребедень и получится. Грамматику надо отправлять на свалку и переписывать по-нормальному.
iconv исходников в cp866 и обратно.
Да просто все символы управления стрипать, их же ограниченное количество. А кто пишет локализацию, тех не выпускать из массива констант.
Выявление bidirectional unicode троянов