Общие принципы

  • Заботьтесь о качестве. Заботьтесь о качестве кода, дизайне и удобстве для пользователей. Стремиться к совершенству.
  • Давайте построим то, чем мы сможем по-настоящему гордиться. Продукт, дающий нам отличную репутацию.
  • Читаемость и ремонтопригодность имеют первостепенное значение. Не будь умным, вместо этого говорите ясно. Не будь неряшливым.
  • Обильно используйте комментарии на уровне исходного текста, чтобы задокументировать дизайн. Прокомментируйте каждый класс, метод и «логические шаги» внутри методов. Вы стремитесь задокументировать вопрос «Почему?» и как?" вопросы.
  • Тестируйте рано, тестируйте часто.
  • Вы не должны усложнять использование классов / модулей. Втягивайте сложность в класс, а не перекладывайте ее на пользователя класса. Сделайте интерфейсы безумно простыми для понимания и использования.

Хлеб и масло

  • Стремитесь сделать код естественно читаемым с помощью имен классов, методов и переменных. Это в дополнение к хорошему комментарию.
  • Используйте единый стиль кода в приложении. Используйте доминирующий стиль в файле.
  • Напишите производственный код качества. Не думайте, что когда-нибудь у вас будет время почистить его.
  • Не проверяйте код с предупреждениями. Разрешите их.
  • Вносите изменения небольшими шагами. Когда шаг станет стабильным / завершенным, проверьте его в своем локальном клоне git. Отправляйте локальные чеки на репо, когда они производственные, стремитесь к ежедневным пушам. Цель здесь - синхронизировать всех, но при этом ничего не нарушать.
  • Добавляйте комментарии «TODO:» к документам, которые были временно пропущены.
  • Не дублируйте код. Если вам когда-нибудь придется копировать фрагмент кода, вставлять его, а затем вносить несколько незначительных изменений. Остановите, проведите рефакторинг и параметризуйте различия.
  • Методов должно быть мало. Используйте это как общий принцип, не злоупотребляйте им. Большой метод - это нормально, если должно быть.
  • Никогда не помещайте логику, зависящую от предметной области, в класс общего назначения. Например. у вас не должно быть общего класса диалогового окна, выполняющего что-то вроде «if (fromActivity instanceOf BooActivity) {}».
  • Стремитесь использовать «принцип локальности» - группируйте связанный код (классы, методы, блоки внутри методов и переменные) вместе. Это также относится к интерфейсам делегирования / обратного вызова. Лучше использовать анонимные классы (объявленные в момент использования), чем объявлять интерфейс в определении класса - не делайте этого: открытый класс FooActivity расширяет BaseActivity реализует VerticalPager.OnScrollListener.

То или это, но давайте сделаем это так

  • Используйте 4 пробела вместо табуляции.
  • Используйте пробелы и комментарии, чтобы выделить «логические шаги». Точно так же ставьте скобки области видимости «{«, «}» на их собственных строках. Вертикальные пробелы - вам не враг.
  • используйте camelCase для имен переменных и методов. «Верхний верблюжий регистр» для имен классов. Строчные буквы для имен пакетов.
  • Начинайте переменные-члены с «m» - mMemberVariable.
  • Начните статические переменные с «s» - sStaticVariable.
  • Используйте скобки области видимости даже для однострочных ifs, for-loops, while-loops и т. Д. Слишком легко испортить область видимости этих операторов. Кронштейны также позволяют лучше выделять блоки.