Заботьтесь о качестве. Заботьтесь о качестве кода, дизайне и удобстве для пользователей. Стремиться к совершенству.
Давайте построим то, чем мы сможем по-настоящему гордиться. Продукт, дающий нам отличную репутацию.
Читаемость и ремонтопригодность имеют первостепенное значение. Не будь умным, вместо этого говорите ясно. Не будь неряшливым.
Обильно используйтекомментарии на уровне исходного текста, чтобы задокументировать дизайн. Прокомментируйте каждый класс, метод и «логические шаги» внутри методов. Вы стремитесь задокументировать вопрос «Почему?» и как?" вопросы.
Тестируйте рано, тестируйте часто.
Вы не должны усложнять использование классов / модулей. Втягивайте сложность в класс, а не перекладывайте ее на пользователя класса. Сделайте интерфейсы безумно простыми для понимания и использования.
Хлеб и масло
Стремитесь сделать код естественно читаемым с помощью имен классов, методов и переменных. Это в дополнение к хорошему комментарию.
Используйте единый стиль кода в приложении. Используйте доминирующий стиль в файле.
Напишите производственный код качества. Не думайте, что когда-нибудь у вас будет время почистить его.
Не проверяйте код с предупреждениями. Разрешите их.
Вносите изменения небольшими шагами. Когда шаг станет стабильным / завершенным, проверьте его в своем локальном клоне git. Отправляйте локальные чеки на репо, когда они производственные, стремитесь к ежедневным пушам. Цель здесь - синхронизировать всех, но при этом ничего не нарушать.
Добавляйте комментарии «TODO:» к документам, которые были временно пропущены.
Не дублируйте код. Если вам когда-нибудь придется копировать фрагмент кода, вставлять его, а затем вносить несколько незначительных изменений. Остановите, проведите рефакторинг и параметризуйте различия.
Методов должно быть мало. Используйте это как общий принцип, не злоупотребляйте им. Большой метод - это нормально, если должно быть.
Никогда не помещайте логику, зависящую от предметной области, в класс общего назначения. Например. у вас не должно быть общего класса диалогового окна, выполняющего что-то вроде «if (fromActivity instanceOf BooActivity) {}».
Стремитесь использовать «принцип локальности» - группируйте связанный код (классы, методы, блоки внутри методов и переменные) вместе. Это также относится к интерфейсам делегирования / обратного вызова. Лучше использовать анонимные классы (объявленные в момент использования), чем объявлять интерфейс в определении класса - не делайте этого: открытый класс FooActivity расширяет BaseActivity реализует VerticalPager.OnScrollListener.
То или это, но давайте сделаем это так
Используйте 4 пробела вместо табуляции.
Используйте пробелы и комментарии, чтобы выделить «логические шаги». Точно так же ставьте скобки области видимости «{«, «}» на их собственных строках. Вертикальные пробелы - вам не враг.
используйте camelCase для имен переменных и методов. «Верхний верблюжий регистр» для имен классов. Строчные буквы для имен пакетов.
Начинайте переменные-члены с «m» - mMemberVariable.
Начните статические переменные с «s» - sStaticVariable.
Используйте скобки области видимости даже для однострочных ifs, for-loops, while-loops и т. Д. Слишком легко испортить область видимости этих операторов. Кронштейны также позволяют лучше выделять блоки.