How to become an author
Search
Write a publication
Pull to refresh

Comments 114

Хорошая инструкция. Всем кто только начинает, советую изучить ее и никогда так не делать.
Total votes 26: ↑22 and ↓4+18
UFO just landed and posted this here
Ух, ох. В целом страдает аргументация и всё очень спорно, странно. Ваши советы действительно сослужат новичкам медвежью услугу примени они их буквально хотя-бы на 50%.

Приведу яркие примеры, чтобы не писать много.
— Про BEM. У нас достаточно большой проект и в нём верстальщиков >10. Больше всех ненавидят единственного применившего BEM. Из за него приходится писать LESS код, где селектор даже в виде исходника не поддаётся чтению, а уж во что он превращается после сборки!
— Какие кавычки брать, зависит от проекта.
— camelCase или через разделитель. Это сугубо проектная договорённость. Лишь бы все действовали в рамках договорённости установленной в самом начале.
— Сокращение это точно не зло, иногда без него селектор 3-4 уровня может превратиться в гигантское 100 символьное убожество.
— Про способы именования классов, способы селектить. По моему опыту, чем больше различных наворотов на тэге — тем сложнее будет селектор. Чем проще — тем лучше, незыблемая истина.

P.S.
Странно, что я не нашёл рекомендации использовать именно 3 пробела вместо табуляции.
Total votes 8: ↑5 and ↓3+2
Лучше всего делать так, как принято на проекте. Может два, может три пробела, а может и табуляция.
Total votes 5: ↑2 and ↓3-1
Проект проектом и тем не менее — во всех языках программирования/разметки де-факто есть предпочтительный стиль.
В js это кэмел, в питоне подчеркивания, в css дефисы. Так делается в абсолютном большинстве случаев.
Сделать в отдельно взятом проекте иначе можно, конечно, но смысл?
Total votes 3: ↑2 and ↓1+1

Например, чтобы не писать в js mySuperPuperBlock(), в css .my-super-puper-block, а в инклудах /my/super/puper/block.

Total votes 4: ↑1 and ↓3-2
А это не проблема, это норма. Потому что каждое из этих написаний будет органично в своем контексте.
Total votes 1: ↑1 and ↓0+1

И вот из-за этой "нормы" программист не имеет простого способа переименовать компоненту, кроме редких случаев, когда IDE заточена под какой-либо фреймворк.

Total votes 1: ↑1 and ↓0+1
Есть хорошее правило для решения этой проблемы: классы — для стилизации, дата-атрибуты — для скриптов.
This comment wasn’t rated yet0
Правило 11 с использованием префикса -js очень удобно в работе, использовав его вы точно будете знать какой класс не надо трогать.
Total votes 2: ↑2 and ↓0+2
Единственное бесспорно годное правило, с которым я согласен.
Total votes 2: ↑1 and ↓10

А я бы поспорил. Если вы до сих пор ищите элементы в доме по селекторам, вместо того, чтобы рендерить дом из дерева компонент, то ваша архитектура безбожно устарела. :-)

Total votes 5: ↑0 and ↓5-5
UFO just landed and posted this here

Ну да, некоторые привыкли с палкой за ними бегать. :-)

Total votes 5: ↑0 and ↓5-5
20. При объявлении селектора в HTML придерживайтесь одиночных кавычек вместо двойных

Почему?
Total votes 12: ↑12 and ↓0+12
Присоединяюсь к вопросу, заранее не согласен с ответом.
Total votes 4: ↑4 and ↓0+4
Автор же объясняет:
но когда дело касается сотни селекторов в HTML-файле, одиночные кавычки — лучшая идея.
Total votes 12: ↑1 and ↓11-10
Почему лучшая идея? Вообще лучше придерживаться одного стандарта с кавычками в HTML.
Total votes 4: ↑4 and ↓0+4
Ну автор же даёт свои советы (видимо в его проектах это помогает), он же не призывает их использовать, о чём и пишет в последнем пункте. Если совет не подошёл, просто пропустите его, да и всё.
Total votes 4: ↑0 and ↓4-4
А вот странный у меня вопрос, а не пофиг ли? Ну оно понятно когда стандартно хорошо, а когда не стандартно, должно же быть плохо? Но как то до сих пор не слышно баталий по этому поводу, никто не страдает, слез не пускает. Вложенный в html атрибут типа data-html="" кусок html с теми же двойными кавычками никак не ломает парсер браузера. никто эти кавычки не видит кроме как в исходном коде… да и даже если видит особо не замечает. Проблем как то ни с js ни с чем то еще вроде бы и нет…
Total votes 1: ↑1 and ↓0+1

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

This comment wasn’t rated yet0
Хорошо, формально это традиция. Чем плоха эта традиция пока я так и не понял. То что «не традиция» — называется «дурным тоном». Так же как писать теги в ВЕРХНЕМ РЕГИСТРЕ. По спецификации HTML допускается вообще не использовать кавычки, но это так же дурной тон.
Total votes 1: ↑1 and ↓0+1
Возможно, автор имел в виду, что одинарные кавычки занимают меньше места визуально, и потому легче воспринимаются глазом. Если это так — то я разделяю его мнение. В HTML, правда, так и использую двойные, а вот в JS только одинарные.
Total votes 1: ↑1 and ↓0+1

В monospaced-шрифте что ', что " занимают одинаковое место.
Я надеюсь на то, что не существует людей, которые пишут код в редакторах, где установлен не моноширинный шрифт...

This comment wasn’t rated yet0
Визуально же. Т.е. больше отступы от соседних символов, легче выделяется содержимое…
Total votes 1: ↑1 and ↓0+1

Да вот фиг знает… Лично для меня использование (в HTML) ' это плохо. Все связано с тем, что с "обоих сторон" кавычки стоят "широкие" символы (...='x...), и в случае использования ' все становится не таким единообразным, что ли…
Ну а отделять содержимое мне помогает подсветка синтаксиса в IDE.

Total votes 1: ↑1 and ↓0+1
Не всякая традиция — хороший тон (см. тж. http://css-live.ru/faq/zabluzhdeniya-razrabotchikov.html). Скорее уж бездумно отбрасывать годную возможность стандарта, потому что когда-то кто-то сказал, что это плохо, а проверить никто не удосужился — дурной тон:)

Если не использовать кавычки, концом значения атрибута будет считаться пробел, поэтому для классов (которые разделяются именно пробелами) без кавычек не обойтись — не потому, что «так положено», а потому, что это логичное техническое требование, прямо вытекающее из синтаксиса языка. У двойных кавычек перед одинарными (как и наоборот) таких технически обоснованных преимуществ нет.
Total votes 1: ↑1 and ↓0+1
Не всякая традиция — хороший тон
Я не говорил, что всякая традиция — хороший тон.
Скорее уж бездумно отбрасывать годную возможность стандарта...
У двойных кавычек перед одинарными (как и наоборот) таких технически обоснованных преимуществ нет.

Вы сами с собой беседуете? Я писал конкретно про кавычки. По теме: освежите в памяти басню «Лебедь, щука и рак».

Если не использовать кавычки, концом значения атрибута будет считаться пробел, поэтому для классов (которые разделяются именно пробелами) без кавычек не обойтись
Для любителей БЭМ это не проблема. Сделают новую тулзу, которая автоматом будет менять пробел на тройное нижнее подчеркивание… (полушутка)
This comment wasn’t rated yet0
Аргумент к традиции сам по себе очень слабый. И басня несколько мимо цели: направления движения одного воза с поклажей являются взаимоисключающими, но стиль кавычек для разных атрибутов — нет. Не шибко красиво, но работать будет.

Более того, вполне могу представить себе экстравагантное соглашение, чтобы функциональные атрибуты (href, value, data-activated и т.п.) ограничивать двойными кавычками, а оформление (class) — одинарными. Чтобы принятая в команде IDE подсвечивала их по-разному и они сразу разделялись визуально. Признаюсь, при первом прочтении статьи я понял этот совет именно так:)

Сделают новую тулзу, которая автоматом будет менять пробел на...

Не сделают. Не получится отличить следующий класс от следующего атрибута (особенно если в ходу кастомные).
This comment wasn’t rated yet0
Мне кажется что в HTML традиционно используются двойные кавычки т.к. это язык разметки текста в котором на английском языке довольно часто попадаются апострофы, для обозначения которых используются одинарные кавычки (напр. " She's great. Don't you think? ")
Поэтому чтобы не париться с постоянным экранированием апострофов — удобнее пользоваться двойными кавычками.

Визуально же одинарные кавычки меньше «рябят в глазах» когда их много, чем двойные. Думаю из этого и следует совет автора.
Total votes 2: ↑2 and ↓0+2
Для апострофа, который символ в тексте, есть специальный символ. Для кавычек в тексте, кстати, тоже (подробнее — habrahabr.ru/post/25531). Не надо путать символы для текста с символами для кода!
Total votes 2: ↑1 and ↓10
В пояснении к пункту:
> Это упрощает чтение документа.
Видимо, для автора так проще вычленить взглядом названия классов при беглом просмотре исходников.
This comment wasn’t rated yet0
В 19 примере часть кода утеряно или я что-то не понял? Объясните, пожалуйста, если все верно.
This comment wasn’t rated yet0
Мне кажется там не должно быть первой строки. Может скопировал неудачно.
This comment wasn’t rated yet0
Я тоже люблю одинарные кавычки. Во-первых, с ними чище, во-вторых, не нужен shift при написании.
Отсюда у меня два вопроса:
1. Почему все не используют одинарные кавычки (в качестве «первых кавычек»)?
2. Откуда пошла мода на двойные? Чем они кавычнее одинарных?
This comment wasn’t rated yet0
Потому что во всех учебниках и документации двойные.
Total votes 2: ↑1 and ↓10
я, например, в JS пишу 
var html = '<div class="test">';
в связи с этим мне проще писать двойные. Тоже самое и с php. Если не ошибаюсь, где то были просчеты, что одинарные кавычки в php работают быстрее, чем двойные. Поэтому и начал обвертывать все в одинарные, что приводит к двойным внутри.
Total votes 5: ↑3 and ↓2+1
Насколько я понимаю, php проводит обработку текста внутри двойных, именно по этому "\s" выведет пробел, а '\s' — \s. Но не думаю, что стоит приплетать php к этому посту, тем более я считаю, что стоит html писать вне тела php скрипта.
Total votes 1: ↑1 and ↓0+1
php включает парсер для строк в двойных кавычках. Приплетать сюда php можно. Есть смысл из-за его особенности.
В нем при выводе html двойные кавычки уже заняты.

<? $html .= "<div class='$variable'>Профиль</div>" ?>

что лучше чем
<? $html .= "<div class=\"$class\">Профиль</div>" ?>


А как то еще изворачиваться через sprintf как то… глупо.
Total votes 2: ↑1 and ↓10

Ну, люди не только на PHP веб делают:)

This comment wasn’t rated yet0
Эта особенность не только у PHP. К примеру, ей обладают те же Perl и Ruby.
Если пишешь на нескольких языках, то поневоле привыкаешь использовать правильные кавычки :)
This comment wasn’t rated yet0

Было бы странно, если бы было иначе, ведь Рубин — законный наследник Жемчужины, А ГипертекстовыйПреПроцессор — его бастард.

Total votes 5: ↑0 and ↓5-5
В вашем примере лучше использовать конкатенацию. Хотя бы просто потому что беглого взгляда будет достаточно чтобы увидеть наличие переменной в строке. Не говоря о том что ваш вариант медленнее (хоть и не столь существенно)

This comment wasn’t rated yet0
Переменная огнем горит, если включена подсветка кода, что очень удобно. А когда нужно где то переменных от 10 вставить в html шаблон, конкатенация, мягко говоря, уменьшает читабельность в разы, добавляя еще один ряд кавычек с точками, по моим ощущениям.
This comment wasn’t rated yet0
Ха… а если посмотреть эти тесты, где конкатенация больше нескольких раз происходит, то выигрышь такой же небольшой выходит при разборе строки.
https://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html
Это 2012 год.
А при наличие опкеша с 5.5 вообще пишут разницы просто никакой.
This comment wasn’t rated yet0
?><div class="<?=$class?>">Профиль</div><?php

Думаю, не стоит напоминать, что есть другие альтернативные способы положить строку в переменную или вывести в тело ответа.
Total votes 1: ↑1 and ↓0+1
Не всегда он удобен. Мне почему то кажется что в вашем примере кое где не рабочее решение
This comment wasn’t rated yet0
Точнее говоря, разве этот вариант везде работает? Разве можно им вернуть результат через return?
This comment wasn’t rated yet0

Нет, "\s" не выведет пробел.

This comment wasn’t rated yet0
Да, Вы правы. Сказалось использование регулярных выражений. Лучше взять в качестве примера \t
This comment wasn’t rated yet0

Там это тоже не пробел, а любой пробельный символ.

This comment wasn’t rated yet0

Там это не любой пробельный символ, а символ табуляции.

This comment wasn’t rated yet0

Где там? Вы целиком диалог посмотрите.

Total votes 1: ↑1 and ↓0+1

«Там», это там, где \t. Диалог я читал целиком, возможно выразился не совсем корректно. Имелась ввиду цепочка вида:


— Там это любой пробельный символ.
— Там это символ табуляции.
This comment wasn’t rated yet0

Диалог не такой был. Мы разговаривали про «\s» в регулярных выражениях.

Total votes 1: ↑1 and ↓0+1
Думаю, исторически так сложилось. Ещё с языка C (может и раньше) строки кавычились двойными, символы – одинарными. Однако, в JS символы являются строками и разницы нет.
Total votes 1: ↑0 and ↓1-1

А я вообще использую Emmet и структура блоков раскладывается сама :)

This comment wasn’t rated yet0
Хорошая подборка советов, но 3 пункт вызывает недоумение.
3. Не называйте класс по содержимому, если картинка нагляднее

Это какой-то антипаттерн. Зачем смешивать модель и представление? Если картинка в будущем изменится, придется переименовывать все стили под новый контент?
Total votes 11: ↑11 and ↓0+11
Есть некоторые отдельные случаи, когда автор будет прав.
Например, в рейтинге использовать класс .star, а не что-то более абстрактное типа .point или .mark
Хотя казалось бы — звездочки это чистой воды оформление и ничто не мешает завтра нарисовать там яблочки, сердечки или пальцы вверх.
Но де-факто если сказать человеку «звездочка» — он мгновенно понимает, о чем идет речь.
Total votes 2: ↑2 and ↓0+2
Используйте префикс js-, если он используется только для JavaScript

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

image

This comment wasn’t rated yet0
довольно странно смотрится 20 пункт, когда в примерах статьи используются одинарные и двойные кавычки. В 6 примере вообще вперемешку одинарные и двойные кавычки. На сайте того же Predicsis используются двойные кавычки.
Total votes 3: ↑3 and ↓0+3
Исправил в 6- и 20-ых пунктах. Но не думаю, что это так критично.
Total votes 3: ↑1 and ↓2-1
Это очень показательно, что даже в десятке строк кода получилась смесь из одинарных и двойных кавычек.
Total votes 10: ↑10 and ↓0+10
  1. Декомпозируйте свои шаблоны и стили на максимально компактные модули, и вам не придется страдать и постоянно выдумывать что-то для поддержания порядка в проекте.
Total votes 1: ↑1 and ↓0+1
Как разработчика, далекого от веба, меня всегда интересовало: а откуда пошла практика именовать селеторы в лисповой нотации «this-is-selector» вместо змеиной «this_is_selector»? Большинство текстовых редаторов воспринимают идентификатор с подчеркиваниями как одно слово, это довольно удобно.
Total votes 3: ↑2 and ↓1+1

Видимо пошло от имен CSS-свойств (z-index, border-left), которые пишутся в пишутся в шашлычном регистре.

This comment wasn’t rated yet0

КМК — удобство. Напечатать - можно одним нажатием на -, а чтобы напечатать _ нужно нажать Shift+-.

This comment wasn’t rated yet0
Не БЭМом единым жив фронтендер. Есть множество различных методологий организации стилей. Каждая из них, как и БЭМ имеет свои плюсы и минусы, и хороши они в разных проектах. На проекте среднего уровня для меня лучшим выбором оказалась MCSS.

Будет полезно ознакомиться с каждой из них хотя бы поверхностно.

А вот остальные пункты из списка даже как-то противоречат конвенции БЭМ, ибо в данной методологии свои правила именования классов элементов блока, классов-модификаторов.

P.S. Про использование классов-пустышек с префиксом «js-» для манипулирования DOM-элементами посредством JavaScript чертовски верно подмечено!

Total votes 3: ↑2 and ↓1+1
Да мёртвые они в большинстве. Я пытался с ними знакомиться в свое время.

BEM вот сразу понятен — ну во всяком случае базовые принципы и с какой стороны к нему подходить. А нюансы уже обкатываются на практике. Кроме того, BEM имеет слабую внутреннюю связность и потому гораздо терпимее прочих относится к смешению подходов.

Остальные… Читаешь, читаешь — вроде и улавливается какая-то логика, но чё с этим всем делать в реальности — непонятно. Вот у меня есть макет, как его верстать? Ни черта не ясно. OOCSS, SMACSS и MCSS в целом педалируют одну и ту же идею плюс-минус частные вариации. И она хоть и имеет определенную внутреннюю логику, но запутанная и сложно применимая в реальной практике. Автор MCSS, кстати, официально объявил, что рекомендует всем переходить на BEM. Atomic CSS вообще мертворожденная чушь.
Total votes 3: ↑2 and ↓1+1
Автор SMACSS тоже сказал что нужно просто использовать BEM: https://twitter.com/snookca/status/606908589295464449
This comment wasn’t rated yet0
Автор MCSS, кстати, официально объявил, что рекомендует всем переходить на BEM.

Вы не могли бы рассказать подробнее, где и когда он такое заявил?
Total votes 1: ↑1 and ↓0+1
https://habrahabr.ru/post/256109/#comment_8442829
Total votes 2: ↑2 and ↓0+2
Попробуйте суффикс -like для лучшей переносимости кода: .h3-like, .h3-title

какой-то странный совет привязываться к h3

Всегда пишите название класса прямо в HTML-элементе, для которого нужно оформление: 
<p class='paragraphly' />

Какая милая безапелляционность. А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?

.c-header-logo

а если такое же лого лежит в футере или где-то в контенте, я уже не смогу переиспользовать класс, получается?

.guillotine {
  /* О, сразу видно, что мы хотим стилизовать */
}

wut?
Total votes 5: ↑5 and ↓0+5
Какая милая безапелляционность. А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?

Смею предположить что имеються ввиду случаи не для текстовых блоков, например как для ссылок в меню и прочее
<nav class="menu">
<a class="menu-link" href="#">1</a>
</nav>

вместо:
<nav class="menu">
<a href="#">1</a>
</nav>
Total votes 1: ↑1 and ↓0+1
Ну, с меню было бы все очевидно, но в примерах приведен именно параграф
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
А если там два десятка абзацев и они вводятся юзером из админки в wysiwyg?
Вы не производите нормализацию пользовательского ввода? Не играйте с огнём.
Total votes 1: ↑0 and ↓1-1
«wut?»

ну, там форма лого на нож гильотины похожа отдалённо
This comment wasn’t rated yet0
а полоса навигации главного меню похожа на прямоугольник, а контентная часть в определенный момент времени похожа на квадрат.
Total votes 2: ↑2 and ↓0+2
и именно поэтому эти названия не говорящие, а «гильотина» сразу подсказывает, о каком элементе речь:)
This comment wasn’t rated yet0
В случае с .c-header-logo думаю можно сделать так:
.c-header-logo, .c-footer-logo, .c-content-logo {… }
This comment wasn’t rated yet0
UFO just landed and posted this here

Я тоже не понимаю этой проблемы. Если ты целый день ничего кроме CSS (и, может быть, лиспа, лол) не пишешь, то кебаб-кейс может и смотрится нормально. А когда надо переключаться с JS (а то и, упаси господь, c Java/C#, в меньшей степени PHP/Python/Ruby), то эта разнобоица как-то совсем ни к чему.

Total votes 1: ↑1 and ↓0+1
> 5. Не используйте верблюжийРегистр
> Это затрудняет чтение
Получается, большинство тех, кто пишет на Java — мазохисты?
Total votes 3: ↑3 and ↓0+3
UFO just landed and posted this here

В яве просто выбора нет, string-builder не является валидным идентификатором.

Total votes 2: ↑1 and ↓10

Окей, окей, был неправ, string-builder является валидным идентификатором в Java.

Total votes 2: ↑2 and ↓0+2
не мазохисты, а придерживаются стандартов языка (как и в Javascript). И да, в некоторых случаях читабельность разбитых на визуальные блоки слов выше. Пробел был не зря придуман
This comment wasn’t rated yet0
Ну, в обосновании этого пункта ни слова про стандарты языка, там лишь безапелляционная фраза «Это затрудняет чтение». Я считаю, что это спорное утверждение и не более чем вопрос привычки.
This comment wasn’t rated yet0
Эта особенность CSS — придумывать и помнить сотни способов для именования классов — просто убивает…
Особенно после изучения пространства имен, например в php.
Total votes 1: ↑1 and ↓0+1
В 4 пункте в примере в css класс называется h3-like, а в html уже h3-title, это опечатка или так задумано и я что-то не понимаю?
This comment wasn’t rated yet0
UFO just landed and posted this here
С сайтом автора действительно какая-то беда приключилась. Но кеш Яндекса пока всё помнит.
This comment wasn’t rated yet0
В №1 перестарался для примера. Кто пэшкам() задаёт классы? Я конечно понимаю в чем суть и пользуюсь этим, но не стоит параграфу задавать класс для стилизации. Если конечно вы не «ТОП-верстальщик», который ни разу не интегрировал верстку с движками.
Total votes 2: ↑1 and ↓10
UFO just landed and posted this here
пункт 10.
а это вообще валидно?


Вообще да, запрещенных символов тут нет.
This comment wasn’t rated yet0
.some_class_name
мне кажется выглядит читабельней, чем
.some-class-name
This comment wasn’t rated yet0
someClassName тоже читается нормально.
Total votes 3: ↑2 and ↓1+1
И после таких статей, пишем статьи, как наши страницы стали в три раза тяжелее…
This comment wasn’t rated yet0
Писать css руками в 21 веке — это деградация.
This comment wasn’t rated yet0
и ассемблер тоже деградация)
This comment wasn’t rated yet0
А деградация причем?) Никуда css не девался и никакие препроцессоры его не убивали
This comment wasn’t rated yet0
Понятно что никуда не девался, просто я говорю о том что вообще его писать руками — это дурная практика тормозящая развитие человечества.
This comment wasn’t rated yet0
UFO just landed and posted this here
11. Используйте префикс js-, если он используется только для JavaScript

Раньше использовал классы с префиксами как в статье, но всегда находил это решение неудобным так как часто ставило в замешательство при наличии 3 и более классов на теге, например так 
<button class="button button_large js-button button_primary pull-right"></button>

В итоге перешел на data атрибуты, с ними сразу видно что на элементе есть JS обработчик
<button class="button button_large button_primary pull-right" data-js-button></button>


6. Пробуйте БЭМ
(двойной дефис) означает вариант элемента.

Вместо двойного дефиса удобнее использовать один символ подчёркивания 
.my-element_modifier

Удобство в том, что выделение через ctrl+shift+left/right на дефисе останавливается, а на подчёркивание — нет. То же самое и с двойным кликом мыши, с подчёркиванием выделиться весь селектор, а без него — придётся делать дополнительные телодвижения.
Total votes 3: ↑3 and ↓0+3
21. Не следуйте правилам

Скорей всего автор имел ввиду: «Не стоит слепо следовать всем этим правилам», потому что сейчас фраза несколько выпадает из контекста и кажется, что автор советует вообще отказаться от идеи следовать любым правилам (не только приведенным в статье) при работе с CSS/HTML, но скорей всего это не так.
Total votes 1: ↑1 and ↓0+1
Имхо, скорее имелось в виду что-то вроде «всегда думайте своей головой и доверяйте своему опыту». Какие-то советы могут быть хороши в 90% или даже 98% случаев, но всегда есть ненулевая вероятность, что на конкретном проекте у конкретного читателя встретится то самое исключение, где разумнее будет сделать ровно наоборот:)
Total votes 1: ↑1 and ↓0+1
Пост теряет всякий смысл своим 21-ым пунктом. Логически получается: «Думайте своей головой» но тогда слишком много пустой воды с очень простым советом.
This comment wasn’t rated yet0
Ну почему. «Знайте 100500 вариантов, но применяйте их не бездумно, а к месту»)
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time
Change theme settings

Your account

Sections

Information

Services

Support
© 2006–2024, Habr