Советы, которых я сам стараюсь придерживаться, и вам советую.

Не вредные советы.

На начальных этапах, на каком бы языке вы не писали, надо придерживаться ряда правил при написании кода.

Есть ряд практик, которые существуют уже давно, и на их базе я для себя простым языком составил список правил и их описание.

Данный список я буду пополнять.

1. Код должен читаться без комментариев - Ваш код должен сам говорить о том, что он делает и как. Например не надо именовать переменные одним символом вроде a. Кроме случаев вроде цикла for(int i = 0; i < maxLength; i++), тут уместно использовать i в качестве итератора. В остальных случаях непонятно для чего ваша переменная и что в ней. Если переменная хранит в себе номер телефона, то назовите ее соответственно phoneNumber, или phone_number. Стиль оформления переменных меняется от языка к языку. Ваши функции и методы должны четко отображать в названии что они делают. То есть, если вы хотите сложить 2 числа в функции или методе, то назовите соответсвенно sum(int a, int b). Чтобы ваши коллеги понимали что данная функция\метод будет складывать числа что вы передаете в качестве аргументов. Так же это правило относится к "магическим числам", это когда у вас в коде используется нечто вроде: peopleCount / 4. Что это за цифра? Откуда она взялась? Создайте константу TABLE_SEATS (места за столом), давайте взглянем: peopleCount / TABLE_SEATS, вот теперь понятно что мы получим кол-во столов необходимое на заданное кол-во человек. 
2. Функция или метод должен делать только одно действие, и ничего больше - соедините с первым правилом, и получится хороший код. Суть в том, что когда ваша функция или метод называется sum(int a, int b), то она должна только сложить переданные ей числа и вернуть\не вернуть результат, в зависимости от реализации. Если вы там же еще и поделите, отнимете, возведете в степень, тогда получается, что функция врет. Со временем вы и сами запутаетесь в том что делает ваша программа, не говоря уже о ваших коллегах. Если вам уж так необходимо в одной функции произвести несколько действий, то дайте более абстрактное название. Но лучше все таки разбить на несколько функций\методов.
3. Не должно быть дублирующегося кода - бывают ситуации, когда надо в разных функциях делать одно и тоже, но с небольшими изменениями. Так вот не надо копировать код из одной функции\метода в другой. Вы плодите одинаковый код. Повторяющийся код должен быть вынесен в отдельный класс, метод\функцию, модуль. В зависимости от масштаба. Я скажу больше, иногда кажется что "ничего страшного тут всего 10 строк дублируется", а потом еще и тут...ну и тут..и тут...ну мысль мою вы поняли. Так вот не допускайте этого, заставляйте себя переписывать.
4. Если функция\метод имеет более 2-х уровней вложения, значит надо вынести в отдельный метод\функцию часть логики - очень частый случай, когда люди называя метод\функцию абстрактным именем, например: "processData()" пишут там 500 строк кода. С уровнем вложенности в 3 и больше  (Уровень вложенности - это количество кода вложенного например в циклы ). Код рабочий, но из за большого уровня вложенности читать его и разбираться становиться тяжело. Поэтому руководствуясь 1 и 2 правилом - выносите часть логики в отдельные методы\функции, чтобы код был более читабельным.
5. Минимальный уровень доступа - ко всем методам, и переменным класса доступ должен быть минимальный, не забывайте о инкапсуляции, ее придумали не зря. Просто приучите себя выставлять минимальный уровень доступа, пока вы в проекте одни, вероятно вы не допустите ошибок, и не перепишите значение переменной класса, которой не должны были. Или не вызовите метод класса, который вызовет исключение, потому что сначала должен был отработать другой метод. Но когда вы работаете в команде, такая ситуация может случиться. 
6. 90% планирование, 10% кодирование - я понимаю, что в большинстве проектов это кажется невозможным. Но постарайтесь попробовать, вы увидите как сократилось количество ошибок, и как увеличилось понимание того, что вы собираетесь сделать.