Pull to refresh

Comments 54

Не могу согласится вот с этим утверждением «Потому, что код несёт в себе и логику и оформление одновременно. А должен нести только логику.» Скомпилированный код для процессора несет только логику. Т.к. отвечает на вопрос «Что делать [процессору]?»

А программный код несет гораздо больше информации. И минимум отвечает еще на два вопроса: «Зачем?» и «Почему?». Правильные названия функций, переменных, скобки, коментарии в важных местах… Каждый раз когда программист читает код, он делает reverse engineering в мозгу, восстанавливая логику работы программы по увиденному коду. И другой программист, как хороший автор, всегда может красиво расставить акценты, облегчив понимание его кода.

А программы автоматического изменения кода — это как перевод стихов промптом — вроде ничего не изменилось, а легкость и красота утратились.
Я не говорил что надо переменные по другому назвать и комментарии удалить, они остаются там где и были, но куча вещей которые мы делаем автоформатированием в коде совсем хранить не нужно, вы же сами знаете как вам удобнее читать десять тысяч строк кода, и предпочтения ваши и автора могут расходиться. Почему нет таких проблем с подсветкой? Потому что она у каждого своя и всё, как хотим так и настраиваем, и каждый читает код так как ему удобно.
Сначала вам не нравится, что у вашего соседа другое форматирование, потом, что он называет переменную my_var вместо myVar, или использует слишком много [по вашему мнению] return внутри функций. Проще договориться.
А может в этом и есть смысл? Договариваться по поводу стиля кода. Если команда не может договорится о такой мелочи, то как она договариваться о действительно сложных вещах?

Договорится о стиле кода: -1 к эго, +2 к командному духу. Кто знает…
Внутри команды без проблем. В что делать когда нужно поддерживать старый или сторонний код? Дело не в том что это можно решить договорённостью, без mvc, и прочих архитектурных решений и паттернов тоже можно писать. Однако их применение решает некоторые проблемы ещё до их возникновения. Данный подход тоже позволит решить такие проблемы совсем, так что получится +1 к эго и +2 к командному духу, разве это плохо?
>>Однако их применение решает некоторые проблемы ещё до их возникновения

часто паттерны решают несуществующие в данном проекте проблемы
Когда вы писали статью, вы использовали лексемы, зачем-то сохраняя их в виде текста, а потом читатель вынужден парсить их назад. Нарисовали бы сразу комикс.
Не художник, выражаю мысль как могу. Да и для общения людей естественный язык пока достаточно хорош.
Код — это в большей степени язык общения программистов, а не программиста и компьютера.
Думал об этом когда писал комментарий, да код — язык общения и программистов между собой и к с компьютером. Почему бы не позволить компьютеру изъять даже повод для разногласий при общении. Ведь цвета подцветки синтаксиса, размер и тип шрифтов не хранятся в файле с кодом и это никому не мешает.
Почему бы не позволить компьютеру изъять даже повод для разногласий при общении.
Наверное, потому, что тогда человек потеряет часть своей свободы. А добровольно на это мало кто пойдёт.

Вообще, вся эта ситуация с табо-пробелами напоминает мне детский сад. Один ребёнок кричит, что его машинка лучше, она красненькая. Второй бьёт его лопаткой по голове и кричит, что лучше его машинка — она грузовик. Третий пытается их помирить и убедить, что обе машинки хорошие, просто разные. А Вы, получается, исполняете роль доброй воспитательницы, которая, дабы прекратить драку, забирает у детей машинки. Предмета спора больше нет, но нет и любимых машинок.
Да нет, я предлагаю одеть очки, и один увидит все машинки одним образом а другой — другим, таким как ему захочется. И каждого будут окружать машинки его любимого типа.
А какие они при этом на самом деле не важно, их скроет абстракция. Вот что я предлагаю.
Понял. Ну что, тоже вариант решения проблемы. Хоть мне он и кажется утопическим.
Когда работали с перфокартами даже думать не могли о современных IDE, не нам ли двигать мир туда куда мы хотим?
UFO just landed and posted this here
Да именно так как вы написали, Вы увидите тот же текст, но вот то как лично вы предпочитаете. Вы увидите тот текст который вам удобен. А я увижу так как мне удобно. вы напишите дополнение, так как вам удобно, а я его прочитаю.
С чего бы. В редакторе тот же текст, только не совсем. Кодите той же клавиатурой. Представление такое как вам нравится. Кто-то может и мышкой, ничто не мешает лексеммы драг энд дропом из словаря таскать. И клавиатурой тоже никто не мешает писать.
Видимо тогда я просто не до конца понял, в чём заключается «отказ от текста».
Отказаться нужно от того чтобы хранить исходный код в виде текста. Хранить его надо уже как результат работы парсера, а программисту выдавать текст в том виде котором он хочет. Ну или не текст если он не хочет текст. Чтобы отделить оформление и логику. Вы захотели чтобы при повышении уровня вложенности команда сдвигалась вправо на один таб равный 4м пробелам, и у вас это так, а в коде это просто не написано, в коде только то, что там, фор, в нём иф, в нйм вызов функции. А уж в каком виде вы это увидите и будете редактировать — ваше дело.
Не слишком портабельно, хотя идея хороша.
Теперь понял. Программа хранит код во внутреннем виде и позволяет отображать и редактировать его используя кучу разных стилей кода.
Ну, идея неплоха, но главный тезис, как по мне, громковат :)
А есть подобный редактор для чего-нибудь кроме AS? Идея понравилась.
Всегда запихиваю текущий code style для проекта в правила форматирования в IDE и потом только автоматическая расстановка отступов, скобок и так далее. Всё!
Не всегда можно просто автоматически расставить скобки, например такая штука часто портится
someFunction() // comment
{
some code
}

Это конечно вопрос правильности IDE но этих проблем можно избежать.
Это какбэ заслуга не RAI а MPS от JetBrains. На котором RAI и написан.
Насчет MPS — да. это будущее. Но не факт, что мы к нему прийдем.
Я думаю что придём, ну или к чему-то подобному.
UFO just landed and posted this here
При том что выбор между табами и пробелами — проблема представления исходного кода. По историческим причинам представление частично хранится в коде, частично в IDE, так подсветка синтаксиса хранится в IDE а отступы в коде. Я говорю о том что отступы и прочие чисто визуальные вещи нужно вынести в IDE и убрать из кода.
UFO just landed and posted this here
Решает, частично и костыльно. Зачем хранить табы вообще? Вот в чем вопрос. IDE продолжит делать то-же самое, ставить табы или пробелы там где вам нужно. Дело не только в табах и пробелах, а вообще в том что сейчас в архитектуре приложений мы идём в сторону разделения логики и представления, а в коде почему-то нет.
UFO just landed and posted this here
Не WYSIWYG, ровно наоборот. Грубо говоря, код записывается в одну строчку только со значащими пробельными символами, а отображает его ваш инструмент так как вам лично (или создателями инструмента, если поленились настройки дефолтные изменить или это невозможно) нравится.
UFO just landed and posted this here
МопедИдея не моя, я лишь попытался объяснить.
UFO just landed and posted this here
Вот вам код, не подходящий на под какие рамки, но по-своему правильный.

if SomeCondition then begin
  y:=x; break; end;


Этим программист говорит: новое значение — x, и стоп! И незачем тратить на такой простой код четыре строчки текста.

А «автоформатирующие» редакторы, как правило, ещё и не могут сохранять синтаксически неправильный текст. Был у меня как-то рефактор, продлившийся два рабочих дня. Ыгы, шестнадцать часов программа не компилировалась. Это был редактор двухмерных уровней, и в дополнение к плиточным уровням надо было добавить графические (т.е. фон полностью нарисован художником или внешней программой). И как изволите такое сохранять?
и не могут сохранять синтаксически неправильный текст
это редактор неправильный. Да и вообще я себе плохо такое представляю, как можно написать огромное количество синтаксически некорректного кода.

А вот code style штука обычно однозначная и я любитель все конструкции писать одинаково, и на вашу потратил бы даже пять, строчки кода это не что стоит экономить. Суть кодстайлов в том чтобы любой код выглядел одинаково, если вы так не считаете, то пожалуйста, я не навязываю свою точку зрения.
С редактором ActionScript я не знаком. С Excel и LotusScript — знаком.

Ну вы как думаете, откуда берётся огромное количество синтаксически неправильного кода? Из рефакторинга, конечно! Тогда мне надо было разбить немаленький класс TLevel на TVirtualLevel и TTileLevel. Ну и добавить TGraphicLevel = class (TVirtualLevel). То же самое — для MDI-окошка редактора уровней. Ах, да: некоторым командам меню нужен только плиточный уровень. Или только графический.
Сейчас еще холивар по поводу египетских скобок начнется.
А что тут холиварить, если египетские скобки однозначно рулят?
то что они не рулят. (Маниакальный громогласный смех разжигателя холиваров)
Решение по ссылке для JavaScript плохое из-за автоматической расстановки точек с запятыми.
И если пример из топика ещё будет работать:
var userList=
[  { name: 'Tom', Age: 5, race: 'cat' }
,  { name: 'Jerry', Age: 3, race: 'mouse' }
,  { name: 'Spike', Age: 11, race: 'dog' }
]

То стоит по привычке или по стайл гайдам написать следующее:
return
[  { name: 'Tom', Age: 5, race: 'cat' }
,  { name: 'Jerry', Age: 3, race: 'mouse' }
,  { name: 'Spike', Age: 11, race: 'dog' }
]


Как всё порушится. Хотя, откровенно признаюсь, что-то в этом есть. Сам иногда использую
ну, некоторые глупости яваскрипта нужно помнить всегда и писать так:

return true && // если мы всё ещё в своём уме, то…
[ { name: 'Tom', Age: 5, race: 'cat' }
, { name: 'Jerry', Age: 3, race: 'mouse' }
, { name: 'Spike', Age: 11, race: 'dog' }
]
Ну после такого поста я просто обязан добавить функционал по выбору стиля фигурных скобок :)
буду премного благодарен. Жаль я не уделил достаточного внимания простоте и тщательности подачи материала и топик слили.
Может вам ассемблер наконец освоить?
или, что уж мелочиться, сразу в машинных кодах писать? чистая незамутненная логика!
Sign up to leave a comment.

Articles