3 ms·
Write simple, clear code. Make sure it's readable. If you come back to something a few days later and you think it's hard to understand, add a comment. Be as c
by gwbas1c 4y ago
Write simple, clear code. Make sure it's readable. If you come back to something a few days later and you think it's hard to understand, add a comment.
Be as consistent as possible with your styles and naming conventions. A large project is significantly easier to read when every class, method, ect, follows very similar style guidelines.
Make sure that you don't need to "think" when reading code. (IE, you shouldn't have to page up and down to remember what type a variable is.) Often this is solved by including type in a variable name, and using some kind of convention to determine scope. (For example, always use "this." so you can tell that a field is a field instead of a locally-scoped variable.)
Try to follow a consistent pattern for line breaks, especially for when a line gets over ~120 characters.
IDEs that let you view code side-by-side on a wide monitor are very useful.
Invest in a giant monitor. I use a 50" 4k TV that I picked up on sale.
Edit: Always be skeptical of frameworks and 3rd party libraries. Put a lot of time into evaluating them, and choose wisely. It's always significantly more work to remote / replace a bad 3rd party framework / library than the time you put into choosing it.
Sometimes "no framework" is easier than a framework. Only writing a few queries? Consider skipping a complicated ORM. A clear startup sequence that builds a shared data structure of long-lived objects might, in the long term, be easier to debug than a complicated dependency injection framework.
Sometimes "no framework" is easier to learn than a complicated framework. Newcomers to your team may appreciate that it's easier to read 1000 lines of simple code instead of needing to spend days understanding a 3rd party framework.
Edit2: Don't underestimate the power of unit tests and automated tests; especially for long-lived industrial-strength software. Take the time to learn how to write good unit tests that you can quickly run in both your development environment and in CI. (Continuous integration)
- gwbas1c 4y agoAnother thing: Be very careful using acronyms. When you use them in code, you better be 110% sure that a newcomer will understand them, or be able to learn them quickly. Instead, try to use the full work and rely on tab completion to save keystrokes.