С принципом бритвы Оккама, конечно, не поспоришь. Но я всё-таки склоняюсь к тому, что добавление «m» уменьшает потенциальное количество багов, потому что есть вероятность забыть про this. Короче говоря, лучше использовать правило 13, то есть согласовывать свой код с тем, что уже есть. Ну или с тем, что принят в качестве корпоративного стандарта.
Для recent suggestions, насколько я знаю, ничего подобного, используя фреймворк, не сделать — нужно писать свой велосипед. Зато в custom suggestions можно предусмотреть соответствующие иконки.
К layout'ам я как раз совершенно никаких претензий не имею. Просто, я считаю, что запомнить 10-15 Активити, с которыми Вы работаете, скажем, пару недель будет проще, если их назвать естественным образом. Это всего лишь моё мнение, кому что ближе.
Суть не в понятности и чистоте кода, а в его правильном документировании, что является стандартом.
Javadocs — стандарт промышленного программирования на Java.
Я со многим почти согласен, но не могу понять почему Вы выбрали такой стиль для именования классов, взять хотя бы активити и адаптеры, Вам не кажется, что логичнее было бы описывать их как ИмяАктивитиActivity (например, MainActivity, SimpleActivity, PhoneActivity, NotesActivity etc.), то же самое для адаптеров (например рассмотрите хотя бы названия стандартных классов для адаптеров — SimpleCursorAdapter, MatrixAdapter etc.).
Для оформления кода достаточно придерживаться этих правил. Конечно, там они в контексте самого проекта Android OS, но для приложений всё то же самое справедливо.
Встречается ситуация, когда setter-метод использует параметры, совпадающие по имени с полями класса, видимо поэтому решили приписать префикс.
Javadocs — стандарт промышленного программирования на Java.
Every method you write, whether public or otherwise, would benefit from Javadoc. Public methods are part of an API and therefore require Javadoc.
Любой public всегда лучше документировать. К тому же слово require — означает «требовать», в отличии от «do not need», что значит «вам не нужно»