Разве «CSS Shorthands» не хороши в командной разработке?

Question

«Сокращения CSS» не годятся для командной разработки?

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

For example:

Должен ли я избежать этого

font: 1em/1.5em bold italic serif

и используйте это

font-size: 1em;
line-height: 1.5em;
font-weight: bold;
font-style: italic;
font-family: serif 

в развитии команды? Какие сокращения являются другими сокращениями CSS, которые не подходят для удобства чтения, а какие хороши?

Answer 1

Когда "пишу код", я склонен быть довольно многословным.Когда такой код, как css / js, запускается в производство, его можно легко минимизировать / оптимизировать с помощью сценария доставки, что дает вам лучшее из обоих миров.

Answer 2

Хотя это явно непопулярно в SO, пара очков в пользу разбиения вещей на несколько строк в командных сценариях:

1) Ясность при использовании контроля источника. С отдельными строками, изменяющимися в системе контроля версий, часто легче справиться и они очень понятны при просмотре журналов изменений.

2) Такие инструменты, как firebug и т. Д., Имеющие корреляцию с точными номерами строк, могут быть полезны при настройке свойств, поиске, сохранении, перезагрузке по сравнению с одним свойством из многих в одной строке.

Answer 3

Если человек работает над редактированием CSS-файлов, он должен иметь возможность хотя бы погуглить его, если сомневаетесь. После того, как достаточно много раз увидишь стенографию, для них это станет второй натурой. Кроме того, им, скорее всего, будет трудно прочитать 5 строк, когда они могли бы прочитать 1 (я знаю, что знаю), чтобы понять, что происходит. Быть более многословным - плохая вещь, когда пытаешься получить много информации.

Читаемость имеет значение, но ее восприятие меняется от человека к человеку. Я нахожу сокращенное выражение более читабельным, даже если мне приходится время от времени выполнять поиск в Google, чтобы убедиться, что порядок правильный. На Python я никогда бы не подумал не использовать @decorators или перечислять понимания только потому, что один пресловутый новичок может найти это странным, это делает мой код короче и, следовательно, более читабельным.

Рука не работает для разработчиков. Заставьте их смириться и выучите язык, за который им платят за создание / чтение.

Answer 4

Это зависит от вашей команды . Хотя лично мне они нравятся, они чисты, лаконичны, и они не так запутаны.

Я бы сказал, что padding: 0 0 5px 0; более запутан, чем ваш пример шрифта, потому что вам нужно знать его верхний, правый, нижний, левый ... с большинством сокращений вы можете читать независимо от порядка и все же легко посмотри, что происходит.

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

Answer 5

Я склонен думать о коде как об однократной записи, часто читаемой. Поэтому я думаю, что короткие руки в порядке, если они очевидны и часто используются, но я думаю, что лучше избегать лишних вещей. Я считаю себя компетентным программистом CSS и должен признать, что сокращение от font-size / line-height является новым для меня.

Answer 6

Код для удобочитаемости (подходит для жизненного цикла проекта)

Использование компиляторов, оптимизаторов и компрессии для повышения производительности

Это относится практически к любому коду, не только к CSS

Answer 7

Чем более читабельным вы сможете сделать свой код, тем лучше.Никогда не принимайте чьих-либо знаний.

Answer 8

Отсюда все выглядит одинаково. Если кто-то не знает, как найти значение параметров для короткой версии, он не в той роли. Также второй занимает больше пропускной способности. Я бы использовал длинную форму, только если вы хотите установить пару параметров вместо всех них