https://github.com/evangipson/developer-pro-tips

A collection of rules to ensure success in your development career.
https://github.com/evangipson/developer-pro-tips

algorithms c-sharp conventions css development-career ecmascript6 git html5 javascript language-conventions vue

Last synced: 3 months ago
JSON representation

A collection of rules to ensure success in your development career.

• Host: GitHub
• URL: https://github.com/evangipson/developer-pro-tips
• Owner: evangipson
• Created: 2016-06-16T18:13:01.000Z (about 10 years ago)
• Default Branch: master
• Last Pushed: 2019-11-13T15:28:30.000Z (over 6 years ago)
• Last Synced: 2025-01-23T04:29:09.017Z (over 1 year ago)
• Topics: algorithms, c-sharp, conventions, css, development-career, ecmascript6, git, html5, javascript, language-conventions, vue
• Size: 40 KB
• Stars: 1
• Watchers: 3
• Forks: 2
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
# Developer Pro-tips

A collection of rules to ensure success in your development career, licensed under Creative Commons Attribution 4.0 International License.

- Understand the full scope

  - If you are making a code change, you need to understand the full scope of that change (the full method, whatever the scope is).

- Look up your project's and language's conventions

  - Look up the naming conventions of the project you're working on and follow them. If there are none look up the language conventions.

  - e.g. C# suggests private stuff gets camelCase and public stuff (things you can see outside of an object) gets PascalCase 

- Before trying to solve a problem, make sure it occurs.

- DRY: don't repeat yourself

  - don't duplicate code and if you must then comment clearly that you are doing so in both places.

- Automate repetitive tasks

  - Before doing something twice, think about if you have to do it a 3rd time (or more.) if so, automate it!

- Null check

  - Protect yourself against data you get from outside your program (like database calls, API calls) with a null check.

  - Always think about where your data is coming from and what happens if you don't get that data.

- Protect your users from evil

  - Doubly protect yourself against data that comes in to your server from users. Always think about what happens if the user is malicious. Be familiar with the [top 10 threats from OWASP](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet).

- Existing code is not holy

  - Just because something is done that way doesn't make a case to do it that way.

  - That said, follow convention if there's no good reason to break it

  - If an existing convention is bad then form a plan to gradually improve it and discuss with your team.

- You are not your code

  - Code may feel like art when you are writing it, but it's a machine built to work. Solicit improvements from peers.

- Your code is your teams' code

  - And vice versa

- Use source control well

  - Look up its conventions too. Here are [10 commandments of good source control management](https://www.troyhunt.com/10-commandments-of-good-source-control/)

- It's harder to read code than to write it

  - Assume the next person to read your code is not you and that you have a sudden onset of amnesia.

- Separate your concerns

  - Write display logic in CSS, write behavior logic in JavaScript, write out DOM structure in HTML.

  - You don't want to call in a JavaScript guy to change an image color, and you don't want to call a CSS guy to add and remove a class from an element conditionally.

- Use for loops when adding and/or removing items from the collection or when the index needs special attention.

  - Conversely, use foreach loops when you don't need the index and aren't adding or removing from the collection.

- How to name things well

  - Describe what the function or variable is doing in a sentence (give the "long form"). What is it actually doing, avoiding programming/generic words (e.g.; "update", "toggle", "handle"). After you have the long name, condense it into a few words and see what you can come up with.

  - A non-programmer should be able to read your variables and function names and understand what they are doing.

- Don't trust package managers to add things correctly to your solution

  - Review each change like you would your own commit (very closely).