Stack Exchange's "codereview" site is the new hotness for this sort of question.

sub node { shift->tree->[0] }
#
sub parse { shift->_delegate(parse => shift) }
#
sub _tag { shift->new->tree(shift)->xml(shift) }

sub tree { shift->_delegate(tree => @_) } 
# т.е. может превратиться в это _delegate(tree => [], deep => 5) или это _delegate(tree => [], 5, 0) 
sub log { shift->emit('message', lc shift, @_) }

sub _instance { ref $_[0] ? $_[0] : $_[0]->singleton }
#
sub find { $_[0]->_collect(@{$_[0]->_css->select($_[1])}) }

Введение

45-я строка ниже края экрана

Полезные ссылки:

1. Контрактное программирование, Программирование по контракту
2. Comparison Preconditions in Java
3. QAPlug vs FindBugs
4. QAPlug tutorials
5. Codacy Home

Описание проблемы

var text = (
`foo
bar
baz`)

var html = `<article>
  <header>
    <h1>${title}</h1>
  </header>
  <section>
    <div>${teaser}</div>
    <div>${body}</div>
  </section>
  <footer>
    <ul>
      ${tags.map(tag => `<li>${tag}</li>`).join('\n      ')}
    </ul>
  </footer>
</article>`

JavaScript quality guide

От переводчика

Введение

private String mName;

1. Как появилась m-нотация.
2. Почему вы, вероятно, не понимаете, что такое венгерская нотация.

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

В нашем случае всё не так просто. Проект, над которым мы работаем, начал свою жизнь ещё до того, как различным стандартам и описаниям лучших практик в среде разработки стали уделять большое внимание. В том числе, задолго до появления столь популярных ныне PSR стандартов для PHP. По этим причинам задача стандартизации кода не ставилась на более ранних этапах, а теперь – предстала нашей команде в качестве вызова.

В этой публикации мы расскажем о том, как пришли к пониманию необходимости единого code style, и выработали методы его постепенного внедрения в масштабный проект. Этот опыт может быть интересен тем, кто пока не использует стандартизацию, но уже ощущает в этом потребность.

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

Поехали!

Есть 3 проблемы кода, с которыми встречаешься в программировании: Хардкод, Говнокод и Шизокод.

Давайте поговорим об этом.