This is a general list for programmers. Feel free to post your own so it can be added to this list!

-1: Check the docs.
0. Avoid using globals except when nessasary.
1. Keep functions and routines small.
2. Don't add comments that "explain" code.
3. Use the proper types for your variables.
4. If you think your code sucks, it does.
5. Have fun.
6. There's probably a better way and
7. it's probably on stack overflow.
8. Write code for humans, not compilers.
9. Back it up.
10. If it doesn’t compile, you’re probably missing a parenthesis or semicolon.
12. Do not be afraid to ask for feedback from the community, but don't be obnoxious or expect any feedback at all- if people have some, they'll give it to you.
13. DEBUG^10
11. Don't forget how to count.
14. Use a clear, explicit naming scheme for variables, functions, and assets.
15. Use slight variations to specify what things are.
16. When debugging, check everywhere for data modifications, not just the main() function.
17. Life isn't an exam, you can phone a friend.
18. Separate your concerns (follow an architectural pattern)
19. For comments, quality over quantity is key, have few very clear comments
20. Most code doesn't need to be extremely cleverly golfed and optimized
21. Write down your ideas
22. It is necessary that you know how to spell.
23. Begging for help makes people want to help you less- check out "how to ask questions the smart way", readily available in the signature of one of our admins.
24. When answering questions or helping people, don't be a jerk. Eventually, you will run into programmers that have a toxic, almost snobbish attitude towards others. Avoid this attitude like the plague.
25. Don't use jargon just to sound smart, or a tool just because it's popular. Use the best solution for the job, even if it is a normal word or an old tool.
Yes, keep functions small, like handle_pending_events().
DrDnar wrote:
Yes, keep functions small, like handle_pending_events().


Yes, see point 4.
6. There's probably a better way and
7. it's probably on stack overflow.
8. Write code for humans, not compilers.
9. back it up
10. if it doesn’t compile, you’re probably missing a parenthesis
2 is pretty close to being objectively incorrect, and 0 simply is objectively incorrect. If this list isn't going to be completely serious, please add a note of this to avoid people from taking this too seriously. Amends have been made, so I'm (mostly) satisfied now.
Maybe this:
12. Get feedback from the community for programs intended for release
13. DEBUG^10
SM84CE wrote:
Maybe this:
12. Get feedback from the community for programs intended for release
13. DEBUG^10


I'd modify these as follows:

12. Do not be afraid to ask for feedback from the community, but don't be obnoxious or expect any feedback at all- if people have some, they'll give it to you.
13. DEBUG^10
11. Don't forget how to count. Evil or Very Mad
14. Use a clear, explicit naming scheme for variables, functions, and assets.
Example: handle_pending_events().
Just by looking at it, I immediately know that it handles pending events.

15. Use slight variations to specify what things are.
Example: Capitalize Functions, not variables.
This helps reduce ambiguity in languages where parentheses specify both parameters and order of operations.

16. When debugging, check everywhere for data modifications, not just the main() function.
17. Life isn't an exam, you can phone a friend.
18. Separate your concerns (follow an architectural pattern)
19. For comments, quality over quantity is key, have few very clear comments
20. Most code doesn't need to be extremely cleverly golfed and optimized
21. Never push code that doesn't work
What do you guys suggest to someone like me - a beginner that has a few ideas that they couldn’t accomplish what I want to make in basic so I am trying assembly - what should I use to code in assembly? I have absolutely no clue. Please help I am really exited to get started Very Happy

Another one though:
22. write down your ideas
mr womp womp wrote:
21. Never push code that doesn't work

Sure you can, but generally not on the master branch Razz
Hehe... I may have inspired -1... Smile
22. It is necessary that you know how to spell.
24:
Quote:
2. Don't add comments that "explain" code.

Yes, keep your code obscure. /s
therad1 wrote:
What do you guys suggest to someone like me - a beginner that has a few ideas that they couldn’t accomplish what I want to make in basic so I am trying assembly - what should I use to code in assembly? I have absolutely no clue. Please help I am really exited to get started Very Happy

Another one though:
22. write down your ideas

Back in my day we wrote code in Notepad Smile

Also I agree SomeCoolGuy, why obscure your code?
CalebHansberry wrote:
Also I agree SomeCoolGuy, why obscure your code?


Your code should be clean enough that it doesn't require comments to explain it.

Edit- also, it's like saying the same thing twice, it's inefficient and wastes both your time and mine.

Edit (serious tips):
11. Begging for help makes people want to help you less- check out "how to ask questions the smart way", readily available in the signature of one of our admins.
12. When answering questions or helping people, don't be a jerk. Eventually, you will run into programmers that have a toxic, almost snobbish attitude towards others. Avoid this attitude like the plague.
13. Don't use jargon just to sound smart, or a tool just because it's popular. Use the best solution for the job, even if it is a normal word or an old tool.
_iPhoenix_ wrote:
CalebHansberry wrote:
Also I agree SomeCoolGuy, why obscure your code?

Your code should be clean enough that it doesn't require comments to explain it.

Edit for #24:
If you think you'll forget what some code does, a concise comment is probably a good idea.
14. Don't write code when you have something more important to be doing.
14.5 Don't write posts complaining about your own poor time management skills when you have something more important to be doing.
SomeCoolGuy wrote:
24:
Quote:
2. Don't add comments that "explain" code.

Yes, keep your code obscure. /s

This is what I mean. And you do it all over the code I've seen Wink

  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement