Сантехник. Чиню протечки в абстракциях. Не дорого.
0,0
рейтинг
15 сентября 2014 в 01:21

Разработка → Принципы написания кода

Прочитав очередные вредные советы про стандарты оформления кода (раз, два, тысячи их), я не смог удержаться, чтобы не поделиться своими измышлениями на эту тему. Долгие годы я вынашивал в своём подсознании чувство «что-то тут не так». И вот, пришло время определиться с тем, что не так, и почему. Рискуя быть закиданным тухлыми бананами, я всё же пишу эту статью тут, а не в своём личном блоге, потому, что это очень важная тема и хочется, чтобы как можно большее число разработчиков поняли её суть и, возможно, пересмотрели свои взгляды на жизнь… кода.

Стандарты кодирования


Типичные проблемы многих таких стайл-гайдов:
1. Плохо обоснована их целесообразность
2. Они декларируют конкретные правила, вместо принципов.
3. Эти правила плохо обоснованы и нередко построены на противоречащих принципах.

В упомянутой статье всё обоснование необходимости стандартизации заключается в:
Хорошее руководство по оформлению кода позволит добиться следующего:
1. Установление стандарта качества кода для всех исходников;
2. Обеспечение согласованности между исходниками;
3. Следование стандартам всеми разработчиками;
4. Увеличение продуктивности.

1. [тут располагается картинка про ещё один стандарт] «Стандарт нужен для того, чтобы был стандарт» — не обосновывает его наличие.
2. В любом более-менее крупном проекте всегда будет куча кода, не соответствующая текущим веяниям моды оформления: изменения стайл-гайда со временем, легаси код, код сторонних библиотек, автогенерированный код. Это неизбежно и не так уж и плохо, как на первый взгляд может показаться.
3. То же что и первый пункт.
4. Уже теплее, но опять же, не обосновывается почему продуктивность от этого должна вырасти, и главное — на сколько.

По своему опыту могу сказать, что самое худшее решение — привыкнуть писать и читать код в каком-то одном стиле, от чего любой код написанный «не по правилам» будет вызывать раздражение, тревогу, гнев и желание навязывать окружающим свои привычки. Куда полезнее научиться воспринимать исходники, игнорируя оформление. И для этого наличие разнооформленного кода даже полезно. Я не говорю, что надо расслабиться и писать всё в одну строку, но, чтобы так не делать, есть куда более практичные причины, чем «стандарт нужен, чтобы всё было стандартно».

Как написать грамотный стандарт:
1. Определился с целями
2. Сформулировать принципы и провалидировать их на соответствие целям
3. Сформулировать минимум правил, для реализации этих принципов

Итак, попробуем


Цель: снизить стоимость поддержки путём наложения на себя и команду ограничений.

В чём заключается поддержка:
1. написание нового кода
2. изменение существующего, в том числе и автоматическая
3. поиск нужного участка кода
4. анализ логики работы кода
5. поиск источника неверного поведения
6. сравнение разных версий одного кода
7. перенос кода между ветками

Какие принципы помогут достичь поставленной цели:

1. Строки файла должны быть максимально независимы.

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

Несмотря на то, что эта простая идея проскакивает в одном из правил упомянутой в начале статьи, в другом же правиле мы видим явно противоречащую рекомендацию:

	.icon--home     { background-position:   0     0  ; }
	.icon--person   { background-position: -16px   0  ; }
	.icon--files    { background-position:   0   -16px; }
	.icon--settings { background-position: -16px -16px; }

Вертикальное выравнивание — это может быть и красиво, но совершенно не практично по следующим причинам:
1. Добавление строки с более длинным именем (например, icon--person-premium) приведёт к изменению всех строк в группе.
2. Автоматическое переименовывание в большинстве случаев собьёт выравнивание (например, при изменении icon--person на icon--user в большинстве инструметов).
3. Иногда пробелы становятся неоправданно длинными, от чего воспринимать код становится сложнее.

Также тут можно заметить лишний семиколон (semicolon, точку с запятой). Единственная причина его появления в этом месте — слепое следование правилам стайл-гайда, не понимая его принципов.
В многострочных правилах, это действительно необходимо, чтобы добавляемые в конец строки не приводили к изменению уже существующих. Например:

	.icon {
		display: inline-block;
		width: 16px;
		height: 16px
	}

	.icon {
		display: inline-block;
		width: 16px;
		height: 16px; /* добавили семиколон */
		background-image: url(/img/sprite.svg) /* полезное изменение */
	}

Если вы пишете на javascript и можете позволить себе отказаться от ie8, то можете использовать хвостовую пунктуацию и в литералах:

	var MainThroubles = [
		'fools',
		'roads',
		'fools on roads',
	]

	var GodEnum = {
		father : 0,
		son: 1,
		holySpirit : 2,
	}

Другой аспект этого принципа заключается в том, чтобы располагать на отдельных строках те сущности, которые меняются как правило независимо. Именно поэтому отдельные css-свойства не стоит располагать в одну строку. Более того, не стоит увлекаться и комплексными свойствами.

	.icon {
		background: url(/img/sprite.svg) 10px 0 black;
	}

	.icon {
		background: url(/img/sprite.svg) 10px 0; /* смещения в спрайте жестко связаны с самим спрайтом */
		background-color: black; /* фоновый цвет меняется независимо от картинки */
	}

Ещё один яркий пример нарушения этого принципа — цепочки вызовов методов:

	messageProto
	.clone()
	.text( text )
	.appendTo( document.body )
	.fadeIn()

Тут мы постарались разместить каждое звено на отдельной строке, что позволяет добавлять/удалять/изменять звенья не трогая соседние строки, но между ними всё равно остаётся сильная связь из-за которой мы не можем, например, написать так:

	messageProto
	.clone()
	.text( text )
	if( onTop ){
		.appendTo( document.body )
	} else {
		.prependTo( document.body )
	}
	.fadeIn()

Чтобы добавить такую логику придётся разбить цепочку на две и исправить их начала:

	var message = messageProto
	.clone()
	.text( text )
	if( onTop ){
		message.appendTo( document.body )
	} else {
		message.prependTo( document.body )
	}
	message.fadeIn()

А вот при такой записи мы имеем полную свободу действий:

	var message = messageProto.clone()
	message.text( text )
	message.appendTo( document.body )
	message.fadeIn()

	var message = messageProto.clone()
	message.text( text )
	if( onTop ){
		message.appendTo( document.body )
	} else {
		message.prependTo( document.body )
	}
	message.fadeIn()

2. Не сваливать все яйца (код) в одну корзину (файл/директорию).

Если вам кажется, что в коде не хватает так называемых «секций», то скорее всего вы подобрались к верхнему порогу восприятия, когда, уже сложно находить нужные его участки. В этом случае естественным желанием является создание оглавления. Но оглавление в виде комментариев в начале файла не сравнится с оглавлением в виде списка файлов в директории. Располагая код в иерархии файловой системы вы довольно неплохо можете упорядочивать всё прибывающее число сущностей. Примерно то же самое вы скорее всего делаете и в рантайме, располагая код в иерархии неймспейсов, так что нет никакой причины иметь для одной сущности разные пространства имён: в рантайме и в файловой системе. Проще говоря, имена и иерархия директорий должна соответствовать именам и иерархии пространств имён.

Часто можно встретить размещение файлов в нескольких больших корзинах: «все картинки», «все скрипты», «все стили». И по мере роста проекта, в каждой из них появляется иерархия, частично одинаковая, но и с неизбежными отличиями. Задумайтесь: а так ли важен тип файла? Пространства имён куда важнее. Так зачем нужны эти типизированные корзины? Не лучше ли все файлы одного модуля хранить рядом, в одной директории, какими бы ни были их типы? Тем более, что типы могут меняться. Сравните:

	img/
		header/
			logo.jpg
			menu_normal.png
			menu_hover.png
		main/
			title-bullet.png
	css/
		header/
			logo.css
			menu.css
		main/
			typo.css
			title.css
	js/
		menu.js
		spoiler.js
	tests/
		menu.js
		spoiler.js

	header/
		logo/
			header-logo.jpg
			header-logo.css
		menu/
			menu.css
			menu.js
			menu.test.js
			menu_normal.png
			menu_hover.png
	main/
		title/
			title.css
			title-bullet.png
		spoiler/
			spoiler.js
			spoiler.test.js

Во втором случае, разрабатывая очередную формочку, вам не придётся метаться между директориями, раскладывая файлы в разные места. В случае удаления компоненты, вы не забудете удалить и картинки. Да и переносить компоненты между проектами становится гораздо проще.

3. Язык программирования — принципиально не естественный язык.

В отличие от письменной речи, которая читается строго последовательно, программный код на современных языках программирования представляет из себя двухмерную структуру. В них зачастую нет, например, необходимости ставить точки (семиколоны) в конце предложений:

	.icon--settings { background-position: -16px -16px; }

	.icon--settings { background-position: -16px -16px }

JS частично понимает двухмерность кода, поэтому в нём семиколоны в конце строк являются тавтологиями:

	function run() {
		setup();
		test();
		teardown();
	}

	function run() {
		setup()
		test()
		teardown()
	}

А вот CSS не понимает, поэтому в нём, без них не обойтись:

	.icon {
		display: inline-block;
		width: 16px;
		height: 16px;
	}

Для улучшения восприятия токенов языка, пробелы могут быть расставлены совсем не по правилам письменной речи:

	say({message: concat("hello", worldName.get())})

	say({ message : concat( "hello" , worldName.get() ) })

	say( document.body , { message : concat( "hello" , worldName.get() ) } )

Для более удобной работы с автодополнением, слова могут изменять свой порядок, выстраиваясь от более важных и конкретных к менее важным и общим:

	view.getTopOffset()

	view.offsetTop_get()

	view.offset.top.get()

А правило именования коллекций с постфиксом «s» (что в большинстве случаев даёт множественную форму слова) в целях единообразия даёт безграмотные с точки зрения английского языка слова:

	for( man of mans ) man.say( 'Hello, Mary!' )

Но это меньшее зло по сравнению с требованием от каждого программиста хорошего знания всех английских словоформ.

5. Полные и одинаковые имена одной сущности в разных местах

Поиск по имени — довольно частая операция при работе с незнакомым кодом, поэтому важно писать код так, чтобы по имени можно было легко найти место, где оно определяется. Например, вы открыли страничку и обнаружили там класс «b-user__compact». Вам нужно узнать как он там появился. Поиск по строке «b-user__compact» ничего не выдаёт, потому, что имя этого класса нигде целиком не встречается — оно склеивается из кусочков. А всё потому, что кто-то решил уменьшить копипасту ценой усложения дебага:

	//my/block/block.js
	My.Block.prototype.getSkinModClass = function(){
		return 'b-' + this.blockId + '__' + this.skinId
	}
	My.Block.prototype.skinId = 'compact'

	//my/user/user.js
	My.User.prototype.blockId = 'user'

Не делайте так. Если склеиваете имя из кусочков, то убедитесь, что эти кусочки содержат полный неймспейс того модуля, где он вводится в употребление:

	//my/block/block.js
	My.Block.prototype.getSkinModClass = function(){
		return this.blockId + '__' + this.skinId
	}

	My.Block.prototype.skinId = 'my-block-compact'

	//my/user/user.js
	My.User.prototype.blockId = 'my-user'

По полученному классу «my-user__my-block-compact» сразу видно, что он склеен из двух кусков: один определён в модуле «my/block», а другой в «my/user» и оба легко находятся по соответствующим подстрокам. Аналогичная логика возможна и при использовании css-препроцессоров, где мы встречаемся с теми же проблемами:

	//my/block/block.styl
	.b-block {
		&__compact {
			zoom: .75;
		}
	}

	//my/user/user.styl
	.b-user {
		@extends .b-block;
		color: red;
	}

	//my/block/block.styl
	.my-block {
		&__my-block-compact {
			zoom: .75;
		}
	}

	//my/user/user.styl
	.my-user {
		@extends .my-block;
		color: red;
	}

Если же не используете css-препроцессоры, то тем более:

	/*my/block/block.css*/
	.m-compact {
		zoom: .75;
	}

	/*my/user/user.css*/
	.b-user {
		color: red;
	}

	/*my/block/block.css*/
	.my-block-compact {
		zoom: .75;
	}

	/*my/user/user.css*/
	.my-user {
		color: red;
	}

Резюме


Продолжать можно было бы долго, но на этом пожалуй закончим. Все проекты разные: где-то нужно быстрое прототипирование, а где-то долгая поддержка; где-то используются статически типизированные языки, а где-то динамически. Важно тут одно — прежде чем объявлять какие-то правила единственно верными, сформулируйте цели, принципы, и убедитесь, что правила действительно им соответствуют и отбросьте всё лишнее. Незачем связывать себя по рукам и ногам, боясь оступиться, если достаточно поставить перила в нужных местах.
Дмитрий Карловский @vintage
карма
6,0
рейтинг 0,0
Сантехник. Чиню протечки в абстракциях. Не дорого.
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (64)

  • +40
    Семиколоны?
    • +40
      Достоевский очень любил использовать семиколоны.
    • –2
      Ещё с пятой колонной разобраться не успели, уже седьмая на помощь спешит…
      • –2
        Гм. Вечером в понедельник шутливый комментарий никого не привлёк, утром во вторник в топик на Хабре заглянули те, у кого ещё не проснулось чувство юмора, и наставили ему минусов. Это была ирония, основанная на игре слов, товарищи, и-ро-ни-я :) Выдыхаем! :)
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      внутрь семиколоны
    • –18
      Точки с запятой не нужны в 99.99% случаев.
      Обычно, если вы склеиваете файлы и в вашем файле код начинается с открытой скобки — это единственное место, где точка с запятой необходима «на всякий случай». И всё. Все остальные места необходимости точки с запятой очевидны для вашего кода (которые, как правило, отсутствуют вовсе).

      Ставить их всегда — это как ходить под зонтом в пределах крыши — а вдруг что-то на голову свалится.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Вы правы, если минификатор сам будет расставлять точки с запятой, а если не будет? Лучше «ходить с зонтом под крышей».
        • 0
          У минификаторов вообще другой взгляд на мир, и они прекрасно понимают код без точек с запятыми. Некоторые, в погоне за размером, вообще перестраивают код с обильным использованием запятых.
          Если минификатор умеет только удалять пробелы и переводы строк в коде — то это фиговый минифактор.
      • 0
        Мне свалилось. Как-то из-за пропущенной точки с запятой образовалась труднонаходимая ошибка.
        • –7
          Если понимать, где их ставить необходимо, где целесообразно «на всякий случай» (исключительно для защиты от кода файлов, которые вы не пишете, если они склеиваются), а где не нужно вовсе — ничего не свалится.
          Касательно стайлгайдов, где рекомендуется ставить везде — новичкам сложно понять где их нужно ставить сходу, и предостережение перерастает в базовый стиль кодирования.
          • НЛО прилетело и опубликовало эту надпись здесь
            • –4
              Ок, вместо дополнения просто оставлю это здесь: www.quizful.net/post/semicolons-in-javascript-are-optional-mmarohnic
              Да, там где-то внизу есть список: (, [, +, -, /, но если ваш файл первой строчкой начинается с чего-то, кроме открывающей круглой скобки — это, по меньшей мере, странно, и про стиль кодирования тут говорить уже глупо.
              Про очевидные места в вашем коде (не в начале файла) имелись в виду скобки (в том числе и квадратные) и, преимущественно, +, может быть ещё и -, как правило в строках --i, ++i.
              • НЛО прилетело и опубликовало эту надпись здесь
                • –3
                  Вот ещё в догонку: habrahabr.ru/post/111563/
                  Там неплохо разложены по полочкам все заблуждения и опасные места. В том числе break, continue, return — но это, как по мне, уже проблемы стиля кодирования, где такое допускается.
                  Конечно, можно писать точки с запятыми везде, где нужно и не нужно, и это, может быть, убережёт вас от лишних проблем. Но это не является необходимостью, правилом или ещё чем-либо таким магическим и единственно-верным. По моему, если в вашем коде есть места, где без точек с запятыми поведение программы непредсказуемо — то проблема в другом.
                  • –3
                    Сюда ещё хотелось бы добавить фигурные скобки и «ставьте их везде во избежание проблем с отступами». Мне нравится coffeescript отсутствием скобок и обязательством ставить отступы. Он как бы обязывает обращать много внимания на важность отступов, и, если бы столько внимания было уделено отступам в js, то никогда не возникло бы проблем с фигурными скобками в однострочных конструкциях условий и циклов.

                    То есть, проще говоря, проблема не там, где кажется.
              • –1
                Ну и да, ещё после i++,i--, но прежде всего стоит подумать, зачем оно такое в коде, если оно лежит вне условия for, где точки с запятыми обязательны. А если оно у вас необходимо, я уверен, что вы вполне понимаете где и зачем ставить точки с запятыми.
          • +1
            Это лишняя вещь для запоминания.
    • –4
      Отличный аргумент, беру на вооружение!

      Если у вас возникают проблемы при склейке или минификации файлов из-за забытого семиколона, значит вы используете кривой инструмент написанный человеком, плохо разбирающемся в семантике языка, который он взялся преобразовывать. Использование кривых инструментов — основной источник ваших проблем, а не раздолбайство программистов.

      Для новичков же есть более полезное правило, чем «ставьте везде семиколоны». Звучит оно так: Если строка не является продолжением предыдущей, то начинайте её с ключевого слова или имени объекта

      Проиллюстрирую примером, проблемного для глупого склейщика кода:

      (function(){
          alert('a')
      }())
      

      (function(){
          alert('b')
      }())
      

      Глупый склейщик соберёт что-то такое:

      (function(){
          alert('a')
      }())
      (function(){
          alert('b')
      }())
      

      И это не будет работать. Более толковый склейщик сгенерирует нечто вроде:
      ;//a.js
      (function(){
          alert('a')
      }())
      ;//b.js
      (function(){
          alert('b')
      }())
      

      Но если придерживаться предложенного мной правила, то даже глупый склейщик ничего не сломает:
      void function(){
          alert('a')
      }()
      void function(){
          alert('b')
      }()
      

      К сожалению, многие писатели мануалов, учебников и стайл-гайдов не в курсе существования оператора void.
      • +8
        Ещё можно себе руку сломать, чтобы спину удобнее чесать было.
        • +2
          Как человек, недавно ломавший себе руку, могу с уверенностью сказать — спину чесать удобней не станет.
          • +1
            К сожалению могу обосновано (вывих) подтвердить: Не станет.
            Я гуманист и сочувствую всем повредившим руку.
            Единственного, кого мне не было бы жалко, — это того, кто разрешил не ставить семиколон в JS.
            Хорошо, что Eclipse считает так же и предупреждает.
      • +4
        > К сожалению, многие писатели мануалов, учебников и стайл-гайдов…
        Не учебников, а туториалов!
        Райтеры туториалов не в курсе экзистенции…
  • +4
    Пример с appendTo/prependTo немного не верный. Цепочки вызовов всё же лучше — они и компактные и читать приятнее, а внедрить логику выбора функции всегда можно:
     messageProto
        .clone()
        .text( text )
        [ above ? "appendTo" : "prependTo" ](document.body)
        .fadeIn()
    

    И вообще, тема со стайл гайдами довольно персональная и абсолютной истинны здесь быть не может, лишь советы — за что спасибо.
    • +2
      Проще метод добавить, который сам внутри принимает решение чё делать.
    • 0
      Интересная конструкция.
      А если аргументы у методов разные?
      • +1
        Если аргументы разные, то это зачастую значит, что и методы выполняют разные смысловые действия, тогда лучше так не группировать.
    • +2
      1. Цепочки сложнее в отладке.
      1.1. Из-за отсутствия переменных вы не можете посмотреть в дебаггере где какое состояние.
      1.2. Вы не сможете поставить точку остановка на середину строки, а при исполнении «по шагам» не будете видеть в каком месте сейчас находится интерпретатор.
      2. При усложнении логики у вас получится лапша в одну строку.
      3. Можете забыть про автодополнение в IDE и сттатические варнинги при вызове несуществующего метода.
      4. Некоторые виды логики нельзя выразить в виде экспрешенов. Например, когда в одном случае нужно два метода вызвать, а в другом один. Или с разным числом и типами параметров. Или в цикле. Или когда нужно временно сменить контекст (я в курсе про костыль в jQuery api.jquery.com/end/)
      • 0
        //cc garex

        Смысловой контекст — вот что имеет значение. Для простого выражения из примера делать отдельный метод нет смысла. Поэтому я сказал, что пример не корректный… Если будем говорить о других более сложных примерах, то `clone/text` нужно заменить на метод `create` с явным созданием элемента (не clone). Вместо `appendTo/prependTo` более гибким решением являются placeholder элементы. Если будем ещё усложнять то тогда уже играют большую роль фреймворки, которые за нас многое что сделают и помогут организовать логику. Поэтому >2 и >4 не релевантные.

        >1: Цепочки разумеется сложнее в отладке, но опять же из примера на `clone/text/append/fadeIn` мне бы не пришлось ставить breakpoint. Там нечего высматривать, более того, в Chrome у меня jquery занесён в список и jquery код пропускается в «step into».

        >3: Я всегда лишь полагаюсь на тесты, если я где-то ошибся с именем, то тест у меня тут же отвалится.

        Конечно у цепочек есть свои недостатки, но так как у них «потоковая» логика, то читать и понимать код в разы проще.
  • +6
    Вот вы тут пишете
    1. Строки файла должны быть максимально независимы.

    Причина проста: если при изменении одной строки требуется изменение других, то это повышает риск конфликтов при слиянии веток.


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

    Не надо так.
    • +3
      Также тут можно заметить лишний семиколон (точку с запятой). Единственная причина его появления в этом месте — слепое следование правилам стайл-гайда, не понимая его принципов.
      В многострочных правилах, это действительно необходимо, чтобы добавляемые в конец строки не приводили к изменению уже существующих.
      Где здесь автор «считает правильным отсутствие точки с запятой»?
      • +1
        Да, действительно. Приношу автору извинения за невнимательность
  • –11
        .icon {
            display: inline-block;
            width: 16px;
            height: 16px; // добавили семиколон
            background-image: url(/img/sprite.svg) // полезное изменение
        }
    

    Вы серьезно используете такие комментарии в CSS?!
    Печальное начало поучительной статьи
    • +5
      Ёпт, здесь просто иллюстрация к тому, какие строки будут показаны как изменённые при использовании vcs diff после добавления background-image. Т.е. автор показывает, что при полезном изменении всего одной строчки diff выдаст изменения в двух.
      • 0
        Поэтому позволительно писать с ошибками? Может ещё текст статьи писать на падонкаффском?
        Я считаю это всё недопустимо, ибо статью читают и новички.
        • 0
          А если уметь читать, что понятно, что автор здесь приводит пример как не надо делать
          • +2
            Да только речь в статье не о комментариях в CSS. Так что BaNru прав.
            К тому же далее в статье уже используется правильный формат комментариев.
            • +1
              Да, в статье речь о точках с запятой в последнем операторе. И автор пишет, что в однострочных конструкциях вроде
              .icon--settings { background-position: -16px -16px }

              точка с запятой не нужна, т.к. её дополнять не придётся, только изменять,
              а вот в многострочных
              .icon {
                      display: inline-block;
                      width: 16px;
                      height: 16px;
                      background-image: url(/img/sprite.svg);
                  }

              надо ставить точку с запятой в конце, чтобы при коммите не было бесполезного изменения с пунктуацией. И приводит пример этого самого корявого коммита.
          • –1
            Там не говорится, что «так комментарии писать нельзя».
            Тут одна ошибка, там другая и вырастит новое поколение адептов попова.

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

            При этом человек учит тут как правильно надо, но сам допускает ошибки. Заметь, именно синтаксису учит, в котором допустил наигрубейшую ошибку.
    • +3
      А кто сказал, что это CSS? Это Stylus.
      Но в конце действительно есть пример с CSS и однострочными комментами. Я его поправлю, раз так сильно режет глаз.
  • +2
    Сколько людей, столько и стилей :)
  • –6
    Ненавижу статьи, в которым меня пытаются научить как «правильно» писать код. Все эти статьи однобоки и лишь выражают субъективный взгляд автора.

    Например, я использую в работе большие мониторы (27"). Для меня вот эта методика разделения кода по строкам крайне не удобна. Получается длинный файл, который нужно долго прокручивать, чтобы что-то найти. Я использую запись кода в одну строку, кроме ветвления. Ветвление у меня организовано «лесенками». В итоге на большом мониторе видно большую часть кода, с которым можно легко работать.
    Я это к чему… Это удобно лично мне, потому что у меня есть деньги на большой монитор. И поэтому я не пропагандирую свой способ и не пишу глупые статьи.
    • +2
      Коллеги помянут вас добрым словом, если им вдруг придется править ваш код на ноутбуке.
      • –1
        Ну, не надо этой истерии. Однострочный код преобразуется в многострочный (и обратно) путем 3 глобальных замен. Смех да и только…
    • +5
      Вам, случайно, никогда не доводилось мёржить код с длинными строками?
      • +1
        Человек работает один со своим кодом — его код, его правила. Вот когда начнёт работать в команде и один и тот же код будут редактировать разные люди тогда придётся поплакать со своими привычками.
    • +1
      Когда я купил побольше монитор я стал смотреть код в нескольких окнах сразу (Vim'овские окна), а не писать всё в одну строчку. У вас ведь не один файл в проекте? Так зачем городить длинные строчки, если можно вместо этого открыть рядышком, к примеру, шаблон, CSS и документацию? Такой вариант здорово разгружает мозги: то, что надо было помнить теперь можно просто посмотреть рядом. Но при этом такая разгрузка не ограничена одним файлом, как у вас.
      • 0
        Мне лично не нравиться переключать постоянно окна для поиска какого-либо куска кода. Мне проще пробежаться глазами по первым 3-4 символам в начале строки, чтобы найти то, что мне нужно.
        • +1
          Vim'овские окна! Вам не надо их переключать, все окна на одной вкладке всегда видны одновременно. А «по первым 3-4 символам» вы

          — Не увидите код, находящийся в том же файле, но за несколько экранов. Если нужно с ним регулярно сверяться, то окна вам помогут, длинные строки — нет.
          — То же самое, но для других файлов.
          — Ну и в вашем коде документации нет, а в соседнем окне открыть её можно.

          Поэтому лучше разделить экран на четыре окна, чем написать строку на весь экран. В IDE обычно тоже есть разные панельки с информацией (документация/отладчик/дерево классов/...) и на них тоже нужно место.
    • +1
      В статье нет конкретного стиля кодрования. Основная идея — всё должно быть обоснованно. Одним из обоснований является простота слияния веток (меньше изменений — меньше конфликтов).

      Внимательно читай статью!
    • 0
      Кстати, тоже заметил это. Чем лучше разбираюсь в том что делаю, чем лучше «пишу программу» тем длиннее получаются строки.
      Одна строка, одна сформулированная часть алгоритма.

      Если потому нужно что-то исправить, то читая код сверху вниз сразу понятно кто за что отвечает и что где происходит.
      А когда код полон переносов и другого сахара, делать это намного сложнее.
  • +3
    bingo!
    Я понимаю, когда используют иностранные слова в тексте на русском языке если нет русского перевода, это упрощает понимание или русский аналог неточно отражает смысл, но «семиколон» — это уже перебор (мое оценочное суждение). Так можно и до «вордов, девайдов, экспрешенов, бранчингов и стейтментов» докатиться. Давайте уважать язык на котором говорим. Спасибо!
  • +3
    Причина проста: если при изменении одной строки требуется изменение других, то это повышает риск конфликтов при слиянии веток. Каждый конфликт — это дополнительное иногда значительное время на его разрешение.


    Именно поэтому я пишу var перед каждой переменной:

    var a = 1;
    var b = 2;
    var c = 3;
    


    В этом случае добавление или удаление новой переменной и проще, и затрагивает только одну строку.
    • +3
      Да, это хорошее правило, +1.
  • +1
    «Не сваливать все яйца (код) в одну корзину (файл/директорию).»

    для хайлоада не очень здорово куча мелких файлов. на продакшне тогда лучше писать компилятор .js и .css в один файл.
    • +2
      Тут речь о разработке, а не о продакшене.
      • –1
        да заради бога. это не отменяет смысла моей ремарки.
    • 0
      Автор про склеивание упоминает ведь.
      • 0
        По полученному классу «my-user__my-block-compact» сразу видно, что он склеен из двух кусков

        это не то, о чем я написал.
        • 0
          Это, оказывается, в комментарии было — по крайней мере имеет представление о вопросе. Возможно, явно порекомендовать всё автоматически склеивать автор просто позабыл, сочтя очевидным (я всегда ожидаю от людей хорошее).
  • –2
    Попахивает какой-то анархией =)
    Ставь пробелы где угодно, пихай лишние запятые в конец массива/хеша, забивай на точку с запятой в конце строки, пиши неграмотные имена…
    Ещё и обоснование прикрутили — так проще) Извините, но НЕТ
  • 0
    Программист очень ленивый и сложный человек, (ну по крайне мере я) и я привык, что за меня все делает IDE и форматирование кода я возлагаю на ее стандарт или на какой то общий между теми IDE, что я работаю. Очень сложно настаивать и переносить форматирование под 100500 студий.
    Когда уже будет одни общий стандарт конфигов? без лишних движений, сел и кодь.
    • 0
      Есть editorconfig. Но он описывает далеко не всё.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.