Comments 6
Грустно наблюдать, что сейчас, в XXI веке человек всё еще должен заниматься тем, чтобы расставлять ключевые слова в правильном порядке и запятые в нужных местах. Важно ли на самом деле то, что функции будут реализованы в том же порядке, в котором они перечислены в интерфейсе? Если сделать 2 шага назад и посмотреть на проблему шире, то можно заметить, что мы всё еще пишем программы очень примитивным способом: набирая каждую букву и каждое слово вручную. Что мы можем сделать для того, чтобы это исправить? Интереснее думать в этом направлении, чем переживать о зяпятых.
Коллега, набирая комментарий, Вы ведь тоже не поленились расставить предложения в правильном порядке и запятые в нужных местах. Потому что ожидаете, что Ваш комментарий прочтут, и читатель должен правильно уловить смысл написанного.
Так и с кодом - разработчики не только пишут код, но и читают - причём, читают гораздо чаще, чем пишут. Поэтому, код должен быть не только грамотно структурирован, но и написан в соответствии с определёнными правилами. Чтобы легко ориентироваться в приложении и быстро читать код, правильно понимать его смысл.
Конечно, давно уже существуют инструменты форматирования кода и предикативного ввода программных компонентов (классов, методов и проч.) - и все мы активно ими пользуемся. Но для того, чтобы грамотно ими пользоваться, мы должны точно понимать, что мы хотим увидеть на мониторе. Что поделать, грамотность никто не отменял.
Выражу свою точку зрения иначе. Представьте, что программа хранится не в виде строки, а сразу в виде синтаксического дерева. Затем представьте, что редактор не разрешает вам писать программу как вы привыкли, буква за буквой. Вместо этого он предлагает вам добавлять элементы сразу в синтаксическое дерево. Дерево выводится на экран в том формате, в каком вы захотите, в зависимости от ваших стилистических предпочтений. Вот это я имею в виду.
Да ну оставьте, какое синтаксическое дерево! Попросите Идею построить Вам, к примеру, диаграмму таблиц базы данных / библиотек зависимостей. Идея построит Вам абсолютно нечитаемую конструкцию. А теперь представьте, как эта диаграмма перебалансируется при добавлении каждого элемента, меняя местами элементы, и начинает жутко тупить, когда количество элементов превышает пару десятков (как начинают тупить динамически изменяемые конструкции любого графического интерфейса). Читаемый код значительно удобнее.
Ну я же совсем не об этом. Дерево это прежде всего структура данных. Дерево можно закодировать как строку символов. Как именно вывести дерево в виде строки символов - зависит от ваших стилистических предпочтений. Я предлагаю редактировать части дерева целиком, а не вводить их по буквам. Программы, которыми мы пользуемся тупят в том числе и от того, что программисты вынуждены делать слишком много рутинной работы.
Лучше рисовать картину не пиксель за пикселем, а крупными мазками. У нас на сегодняшний день нет инструментов, которые позволят писать программу "крупными мазками". Хоткеи для создания классов это не то, что нужно.
Отлично! Просто великолепно!
Хабр опустился до тупых репостов.
Всю статью можно смело выпилить, заменив ссылкой на community перевод официальной документации.
Автор, не стыдно, вообще, заниматься репостом?
Kotlin Coding Conventions