Pull to refresh
  • by relevance
  • by date
  • by rating

Красив ли код???

Lumber room
int get_ones_count(int x)
{
x = (x & 0x55555555) + ((x & 0xAAAAAAAA) >> 1);
x = (x & 0x33333333) + ((x & 0xCCCCCCCC) >> 2);
x = (x & 0x0F0F0F0F) + ((x & 0xF0F0F0F0) >> 4);
x = (x & 0x00FF00FF) + ((x & 0xFF00FF00) >> 8);
x = (x & 0x0000FFFF) + ((x & 0xFFFF0000) >> 16);
return x;
}

Красив ли данный код? Почему?

Вообще интересно почитать мысли на тему красивый/не красивый код.

p.s. По-моему мнению код должен быть понятный.

p.p.s. Данный код вычисляет количество единичек в двоичной записи числа.
Total votes 41: ↑32 and ↓9 +23
Views 314
Comments 203

Что такое красивый код, и нужен ли он? Что думают в Яндексе

Яндекс corporate blog Programming *Perfect code *
В Яндексе работает больше 6000 человек, и, по некоторым оценкам, больше половины наших сотрудников имеют опыт в программировании. И конечно же, у каждого из этих людей есть своё самое правильное мнение о том, каким должен быть идеальный код.

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

Чтобы понять, какие свойства кода отстаивают разные стороны, я по горячим следам очередных бурных обсуждений решила спросить коллег, что такое красивый код и должен ли он вообще быть красивым? Достаточно того, чтобы он хорошо работал и был понятным? Или понятный код по умолчанию красивый?



В опросе участвуют bobuk, anatolix, anton, Андрей yafinder Плахов, Антон Самохвалов, Андрей Гулин, Владимир Иванов и другие. Суммарный опыт программирования всех участников этого микроинтервью на восьмерых составляет 198 лет.
Читать дальше →
Total votes 194: ↑164 and ↓30 +134
Views 82K
Comments 141

Размышления о красивом коде

Programming *Perfect code *
Sandbox

О красивом коде много принято говорить, рассуждать, спорить, и тем не менее, все равно толком не ясно — что же такое «красивый» код и каким он должен быть. Сложность определения «красоты кода» неудивительна, ведь понятия о «красоте» у каждого свои, не только в мире программ, но и вообще, в мире людей. Тем не менее, существуют определенные общие критерии красоты, с которыми соглашаются большинство людей. Их сложно сформулировать, но подсознательно любой человек понимает, что вот эта вещь — красива, а эта — не очень.
Не так давно, был опубликован очень интересный опрос, разделяющий мнения разработчиков о красивом коде, согласно их опыту. На мой взгляд, получилось крайне интересное исследование. Давайте попробуем порассуждать о нем немного шире.
Читать дальше →
Total votes 25: ↑16 and ↓9 +7
Views 17K
Comments 6

Именованные аргументы функции в C

Abnormal programming *Designing and refactoring *C *
Sandbox
В некоторых языках существует возможность вызова функции с именованными параметрами. Такой способ позволяет указать аргумент для определённого параметра, связав его с именем параметра, а не с позицией. Это возможно, например, в C# или Python.

Рассмотрим «игрушечный» пример на Python с использованием именованных аргументов:

#вычислим объем параллелепипеда
#если значение стороны не указано, то считаем что оно равно единице
def volume(length=1, width=1, height=1): 
  return length * width * height; 
print(volume())                            # V = 1 
print(volume(length=2))                    # V = 2 
print(volume(length=2, width=3))           # V = 6 
print(volume(length=2, width=3, height=4)) # V = 24

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

Ниже я покажу, как можно сымитировать использование именованных аргументов в C.
Читать дальше →
Total votes 33: ↑28 and ↓5 +23
Views 14K
Comments 12

Пирамида Маслоу в аспекте разработки ПО

Website development *Programming *
Sandbox
Предлагаю читателям «Хабрахабра» перевод заметки «Maslow's Hierarchy of Needs of Software Development», которую я нашел в блоге Скота Ханселмана.

Я тут немного экспериментировал со своей диетой и думаю перейти на «палео»-диету. Впрочем, это очень самонадеянно c моей стороны, вот так вот, в корне, изменить свое отношение к еде. В наше время только весьма обеспеченные люди могут позволить себе в полной мере экспериментировать в этой области.

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

image

Недавно я общался с заказчиком, где один хороший человек большей частью был озабочен стилем кода: расположением фигурных скобок, применением проверенных решений («best practices») в дизайне интерфейсов и еще кучей важных, но едва ли критичных вещей. В то же время в их организации не было поставлено модульное тестирование («unit-testing»), развертывание («deployment») проводилось вручную, а сборки были слабо верифицируемыми («verifiable build»).

Говоря иначе, он был сосредоточен на проблеме «достаточно ли я потребляю витамина А?», упустив из виду проблему «есть ли у меня вообще что приготовить к ужину?».

Я подумал: что если спроецировать пирамиду потребностей Маслоу на нашу предметную область — разработку ПО? Под катом пример того, что у меня получилось (благодарю Фила Хаака, Джона Галлоуэя, Джонатана Ванагела и Пола Стовела за участие в «мозговом штурме»).
Читать дальше →
Total votes 20: ↑19 and ↓1 +18
Views 20K
Comments 7

Что такое красивый код, и как его писать?

Programming *Perfect code *
Sandbox

1. Вступление


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

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

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

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

Говоря о базовых знаниях, надо отметить, что умение писать красивый профессиональный код — это то, что по тем или иным причинам, в эти базовые знания категорически не входит. Вместо этого, в соответствующих заведениях, а также в книжках, нам рассказывают про алгоритмы, языки, принципы ООП, паттерны дизайна…

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!
Читать дальше →
Total votes 97: ↑79 and ↓18 +61
Views 183K
Comments 145

Архитектура кода

System Analysis and Design *Designing and refactoring *Interfaces *
В этой статье я хочу поделиться своим личным опытом, связанным с правильной организацией кода (архитектурой). Правильная архитектура существенно упрощает долгосрочную поддержку.
Это очень философская тема, поэтому я не могу предложить ничего более, чем мой субъективный анализ и опыт.

Проблемы, симптомы


Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.

Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.

У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.
Читать дальше →
Total votes 44: ↑41 and ↓3 +38
Views 49K
Comments 25

Размышления о красоте и коде

Programming *Perfect code *Designing and refactoring *Brain
Думаю, у каждого разработчика рано или поздно возникают в голове мысли о том, что код нужно писать определенным образом. Почему фреймворк этого автора так прост в использовании, и погружение в него проходит так быстро? Почему данный кусок кода кажется мне ужасным? В этот момент происходит важный виток в развитии разработчика как профессионала. Он не только начинает задумываться о том, как ему реализовать конкретную задачу, но и том, как оформить свое решение. В голове начинают зарождаться мысли об определенном структурировании кода и красивом его оформлении. Кто-то начинает создавать для себя некий эмпирический набор правил по оформлению кода, кто-то приходит к помощи литературы или совету более опытных товарищей. В любом из этих сценариев код начинает рассматриваться не просто как безусловное решение проблемы. Появляются мысли о том, что некоторая часть кода сделана некрасиво, а вот здесь получилось круто и элегантно. Но кто определяет эти критерии красоты относительно кода и что в них закладывается? Однозначно ли все в вопросах кодового этикета и красоты?

Disclaimer: эта статья ставит перед собой целью поделиться мыслями, возникшими в процессе попытки осмыслить понятие красивого кода. Приведенные мысли не претендуют быть истиной в последней инстанции. Надеюсь лишь на то, что эти мысли, размышления и доводы, возможно, помогут кому-то взглянуть на сам процесс написания кода немного с другой стороны. Далее не следует ни одного формального правила вида «Пишите код так, и будет вам счастье». По данной тематике уже написан большой объем литературы от гораздо более уважаемых авторов.

Всех заинтересованных в рассуждениях на тему, что такое красота кода, в чем она может выражаться, почему все известные практики не в силах закрыть раз и навсегда этот вопрос, прошу под кат.
Читать дальше →
Total votes 9: ↑7 and ↓2 +5
Views 6.3K
Comments 13

Что такое красивый код и как научиться его писать

Яндекс.Практикум corporate blog Programming *Perfect code *Studying in IT IT career
Tutorial
Меня зовут Маша, я автор курса по С++ в Яндекс Практикуме. Все вопросы, задачи курса, его тексты и описания решений — это всё наша команда. И сегодня я хочу поговорить про красоту кода. Обсуждать её я буду по большей части на примере С++, так как я на нем и пишу, чаще всего программируя довольно низкоуровневые проекты для устройств интернета вещей, умного дома и медицинских аппаратов. Но сами правила и подход к пониманию красоты кода актуальны для любого языка.

Если совсем базово, то можно выделить три уровня красоты кода:

  1. Визуальный. Это как раз все про coding conventions, правильные переменные, оформление и прочее.
  2. Восприятие кода. Про ощущения, которые возникают у людей, работающих с вашим кодом.
  3. Продуманность архитектуры. Это тоже критично и тоже относится именно к красоте кода.

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

А теперь давайте по каждому пункту отдельно.


Читать дальше →
Total votes 45: ↑40 and ↓5 +35
Views 20K
Comments 39