![\"Guidelines](\"http:\/\/strawberrycode.com\/blog\/wp-content\/uploads\/2016\/09\/GuidelinesDevelopers_banner.png\")
<\/p>\nHere are some rules or guidelines I try to live by as a developer. They are for all of you, from the beginners to the seasoned developers.
\nIt is not an exhaustive list, so feel free to add yours in the comments below!<\/p>\n
<\/p>\n
1. “Temporary” doesn’t exist in development<\/strong> 2. Use meaningful variable names<\/strong> 3. Be consistent with style, use guidelines<\/strong> 4. Throw and catch your errors, or handle them<\/strong> 5. If there is an IF, there should be an ELSE<\/strong> 6. And if you’re ignoring something on purpose, leave a comment<\/strong> 7. No line of code should be left untested<\/strong> 8. Write readable code<\/strong> 9. Write unit tests whenever possible<\/strong> 10. If something doesn’t feel right (eg. UX or UI), say it!<\/strong> 11. If you have a doubt about a feature, ask!<\/strong> 12. Reuse code, create libraries… don’t repeat yourself<\/strong> 13. Look for best practices and code optimisation<\/strong> 14. If it takes 1 extra hour for you to do something that can save 10 mins to each user every day, do it!<\/strong> 15. If something is not straightforward, put a comment<\/strong> 16. Keep changes in separate commits<\/strong> 17. New feature = new branch<\/strong> 18. Try to merge the main branch to your feature branch as often as possible<\/strong> 19. When committing, do a 20. Write meaningful commit messages<\/strong> 21. Do not alter too much the merge messages<\/strong> 22. When doing a big merge, create an intermediate branch<\/strong> Bonus: don’t push something live on a Friday night, or right before your holidays…<\/strong> Most importantly, Here are some rules or guidelines I try to live by as a developer. They are for all of you, from the beginners to the seasoned developers. It is not an exhaustive list, so feel free to add yours in the comments below! 1. “Temporary” doesn’t exist in development Be honest with yourself, you’re never going to change it. Ever. 2. Use meaningful variable names Because abc, test or tmp are not really understandable by other developers, or by you in 6 months. 3. Be consistent with style, use guidelines Some are immune to it, but unfortunately (or not), it … Continue reading Guidelines #1 for Developers<\/span>
\nBe honest with yourself, you’re never going to change it. Ever.<\/p>\n
\nBecause abc<\/code>, test<\/code> or tmp<\/code> are not really understandable by other developers, or by you in 6 months.<\/p>\n
\nSome are immune to it, but unfortunately (or not), it drives me insane. So try to agree on some basic rules with your team on indentation, spaces, return, etc.<\/p>\n
\nI know, it’s easier said than done. And some languages are more error-friendly than others. Try to integrate it as early as possible in the process, it will be easier to do.<\/p>\n
\nOr some sort of fallback. Try to cover all cases ;)<\/p>\n
\nOr a TODO, it’s okay.<\/p>\n
\nAlways test what you do, don’t expect things to work straight away. No offense, but you’re not that good ;)<\/p>\n
\nBecause the code is READ by humans and executed by machines.<\/p>\n
\nSame as the “throw and catch errors”.<\/p>\n
\nYou’re often the first one who will see it in action.<\/p>\n
\nDon’t take decisions if it’s not your role, you may end up redoing the whole thing.<\/p>\n
\nThink DRY, live DRY, eat DRY, drink DRY, sleep DRY. Oh, what did I just do??<\/p>\n
\nIt cannot hurt, right?<\/p>\n
\nDo the math, it works! And you would do it for yourself, so do it for others ;)<\/p>\n
\nI’m talking about nice and short explanations when the code doesn’t speak for itself.<\/p>\nFor Git users, or users of other versioning systems (hopefully everyone):<\/h3>\n
\nIt’s easy to keep on working on the same commit, but it gets more painful when you need to revert.<\/p>\n
\nUnless you want to do it the hard way, of course.<\/p>\n
\nIt makes life easier when you need to merge it back to the main branch.<\/p>\ngit diff<\/code>, and read it!<\/strong>
\nIt helps to double-check what you just did and sometimes to clean the code too.<\/p>\n
\nNo, “fixed bugs” is not sufficient in most cases.<\/p>\n
\nThey can contain useful information by default.<\/p>\n
\nIf you’re merging B into A, the intermediate branch is basically a copy of A where you merge B to see if everything goes well.<\/p>\n
\nUnless you really want to spend time on it when you shouldn’t, that’s up to you :)<\/p>\n
\nStay curious, be consistent, be sensible, have fun!
\nIf you don’t know something, Google it or ask someone.
\nAnd try to learn something new every day!<\/p>\n","protected":false},"excerpt":{"rendered":"