chevron_left chevron_right
Login Register invert_colors photo_library


Stay updated and chat with others! - Join the Discord!
Thread Rating:
  • 0 Vote(s) - 0 Average


Tutorial The do's and don'ts of programming filter_list
Author
Message
The do's and don'ts of programming #1
Programming is easy, everybody and their brother can do it, but can they do it right? Anybody who has ever touched code knows that there are struggles, mishaps, and the occasional fire. What if I told you that over 90% of that was preventable. Witchcraft you say? nay. If you sit back long enough, I will give you a brief rundown on what you should and should not do while programming.

Why don't we start with common mistakes?

1. inconsistent style:
[Image: aRQneE2_700b.jpg]
Every programmer has heard this over and over. Where do braces go? How much whitespace should I add? Are there one space or two spaces after a sentence dammit!
The answer really is not that simple. Everybody has their own style, some languages enforce a certain style (Python, I'm looking at you), and some people start crusades over which is the best. Style really isn't important, as long as you stick with it. Inconsistency anywhere in your code base is a recipe for disaster. If you decide to use the same line opening brace, (at your own risk, we will talk about that later), then so be it, but stick with it for the entirety of the job. If you decide to use spaces for tabs (may God have mercy on your soul), make sure you use exactly the same number for EVERY level. ie: don't use 4 spaces for the first tab, then 3 for the others (Eclipse is notorious for doing shit like this). If your IDE has a specific style, then it's fight or flight. Either change it from the start, or submit to it.
many programming errors are made because of bad styling



2. random variable names
[Image: mW1Lf.png]
This is by far the worst habit I have ever seen. This isn't high school algebra anymore, variables are plentiful in an application, and they all have very different meanings. Some are numbers, some are text, hell some might even be dick pics! What would you do if you solved a simple y=mx+b to find that x=-5 and x=myDick? Exactly. Don't be stupid, don't name variables 'shit' or 'blarg' (I used to do things like this, until one hit production and threw a page fault). MAKE YOUR VARIABLE NAMES USEFUL![b]. They don't have to be 30 words long, and they don't have to follow the Pascal naming scheme (but be consistent), but make them useful. For example, here is a snippet of code from one of my current projects:
Code:
@interface R3EventInfo ()
@property (weak, nonatomic) IBOutlet UILabel *l_when;
@property (weak, nonatomic) IBOutlet UITextView *l_description;
@property (weak, nonatomic) IBOutlet UILabel *l_address;
@property (weak, nonatomic) IBOutlet UILabel *l_attending;
@property (weak, nonatomic) IBOutlet UIButton *b_prevPage;
@property (weak, nonatomic) IBOutlet UIButton *b_nextPage;
@property (weak, nonatomic) IBOutlet UIButton *b_0;
@property (weak, nonatomic) IBOutlet UIButton *b_1;
@property (weak, nonatomic) IBOutlet UIButton *b_2;
@property (weak, nonatomic) IBOutlet UIButton *b_3;
@property (weak, nonatomic) IBOutlet UIButton *b_4;
@property (weak, nonatomic) IBOutlet UIButton *b_5;
@property (weak, nonatomic) IBOutlet UIButton *b_6;
@property (weak, nonatomic) IBOutlet UIButton *b_7;
@property (weak, nonatomic) IBOutlet UIButton *b_8;
@property (weak, nonatomic) IBOutlet UIButton *b_9;
@property (weak, nonatomic) IBOutlet UIButton *b_10;
@property (weak, nonatomic) IBOutlet UIButton *b_11;
@property (weak, nonatomic) IBOutlet UIImageView *i_0;
@property (weak, nonatomic) IBOutlet UIImageView *i_1;
@property (weak, nonatomic) IBOutlet UIImageView *i_2;
@property (weak, nonatomic) IBOutlet UIImageView *i_3;
@property (weak, nonatomic) IBOutlet UIImageView *i_4;
@property (weak, nonatomic) IBOutlet UIImageView *i_5;
@property (weak, nonatomic) IBOutlet UIImageView *i_6;
@property (weak, nonatomic) IBOutlet UIImageView *i_7;
@property (weak, nonatomic) IBOutlet UIImageView *i_8;
@property (weak, nonatomic) IBOutlet UIImageView *i_9;
@property (weak, nonatomic) IBOutlet UIImageView *i_10;
@property (weak, nonatomic) IBOutlet UIImageView *i_11;
@property (weak, nonatomic) IBOutlet UIScrollView *v_content;
@property bool b0IsRequests;
@property unsigned int pageNum;
@property unsigned short actid;
@property unsigned int myuid;
@property vector<unsigned int> shownProfiles;
@property vector<unsigned int> profiles;
@property vector<UIButton *>buttons;
@property vector<UIImageView *>images;
@property activity_create_dta data;
@end
Now, I know that all buttons (and the image views layered on top of them) are aligned in a grid, so they don't need placement names. I prefixed labels with l_, buttons with b_, views with v_, and them private data has no prefix. All of the variables are on different lines, this helps spot type differences. I also follow Pascal naming convention (by preference). Long story short, you will code how you want, but if you practice with a good structure, you will see results. Yes, your code will be long as hell (we will cover that), but it is worth it.



3. variable typing: on the fly vs compile time
[Image: phpcode.png]
Some languages (PHP, javascript, python, etc) allow you to declare a variable at runtime, and whenever you want. This is a neat little tool, but it isn't used as it should be. In essence, you should know [b]EXACTLY
what variables you need from the start. Dynamic definitions is a scoping feature, NOT a convenience. If you have a function that does something, and you need three variables, don't define them the first time you use them, define them at the top of the function! This goes for languages like C as well (older versions actually forced this). I have been caught a few times forgetting a variable name and digging through it, it sucks, avoid it.



Ok, now that we have hit the major issues, let's have a talk about when disaster does strike, and how to make our code a little bit easier.

1. BossCode,php
Everybody has forgotten a brace somewhere, and finding the missing one isn't always easy. I actually had code given to me, where the end of the file looked like this:
Code:
die("Some error message");
}
}}}}}}}}}}}}}
?>
Now, this is where many programmers will disagree with me, but the problem with why this code did not function properly was by doing things like this:
Code:
if (something) {
  statement;
  statement;
  if (another) {
    statement;
  } else {
    statement
} else
  statement;
Did you spot the missing brace? Maybe, but I bet I threw a couple of you off.
Spoiler:
Code:
if (something) {
  statement;
  statement;
  if (another) {
    statement;
  } else {
    statement
******************************missing closing brace was here
} else
  statement;
Now, if I rewrote the same code in the other style:
Code:
if (something)
{
  statement;
  statement;
  if (another)
  {
    statement;
  }
  else
  {
    statement
}
else
  statement;
then I'm sure it becomes obvious, you can use a line of sight to find it!.



2. Code density
[Image: jCRea8A.jpg]
That image is actually from one of my projects. Unfortunately it couldn't be helped, and that happens sometimes. Some of you might not see anything wrong with that, but as the code gets larger, then you will have to dig through a lot of whitespace to find what you're looking for. Now, I'm not saying throw a bunch of junk onto one line, but try to write complex code that can do more than one thing, or at least utilize a lot of power for its line. Here is a screenshot from another part of the code
[Image: q5FI4Qa.jpg]
Notice that it is much more dense? That little bit of code has more importance than the entire file from the example above, yet it is still easy to read, it is still broken up into chunks, it just does a lot more per line.



3. documentation
As some of you may have noticed, my code lacks comments for most cases. There is a reason for this. If any of you know the languages I have used (C, objective-C, PHP), then you will find that you can read through it with ease and you don't need comments. Comments are just that, a comment. They aren't a book, don't comment every line (I had a job that required that, and most of our comments were crude love stories, which made it harder to read than none at all). If you use good variable names, name your functions right (and maybe even describe the functions at their definitions), write dense code, and don't do weird things, then your code won't need many comments. write your code as if the guy who will have to maintain it is a serial killer who knows where you live. Comment where things get fuzzy, If you might forget it, add a comment.



Now, I said 'when disaster strikes', but I didn't talk about it. That's because really that's what this entire post is about. If you follow all of these, then you will find yourself making less careless errors (I haven't had a program fail to compile in years, it isnt a big deal anymore, my bugs are far worse), and when it comes time to debug that issue you will have a much easier time.


Well, let me know what you guys think, if I missed a major point feel free to tell me.

[+] 2 users Like phyrrus9's post
Reply

RE: The do's and don'ts of programming #2
Thank you for this thread, this has helped me greatly, i am one of those people who use inconsistent style and i did not think it was an issue but after seeing this thread i realized that it does have some importance so i will try my best to stick to one style. Thanks Smile

Reply

RE: The do's and don'ts of programming #3
Well written & informative, thankyou for the read.

Bookmarked for when I decide to learn coding at all.????
'You can't just have your characters announce how they feel, that makes me feel angry! [Image: A993dMx.png?1]

Reply

RE: The do's and don'ts of programming #4
Be careful when you say programming is easy. I tutored Comp Sci for a while and to some it comes easy but most people know shitall about programming even after applying themselves for a semester. In fact, I'd say most don't know/can't program for shit (talking about my exp with college students) if they are not a Comp Sci major. It takes a certain patience and interest.


other than that great guide.
[Image: pBD38Xq.png]
Email: insidious@protonmail.ch

[+] 1 user Likes insidious's post
Reply

RE: The do's and don'ts of programming #5
(08-23-2016, 06:21 PM)insidious15 Wrote: Be careful when you say programming is easy. I tutored Comp Sci for a while and to some it comes easy but most people know shitall about programming even after applying themselves for a semester. In fact, I'd say most don't know/can't program for shit (talking about my exp with college students) if they are not a Comp Sci major. It takes a certain patience and interest.
other than that great guide.

Maybe your tutoring was at fault? Programming in essence is just understanding structure. If you can speak any language, you can learn to program. How your brain is wired may effect which language is easier to learn, but it's fundamentally simple.

[+] 2 users Like phyrrus9's post
Reply

RE: The do's and don'ts of programming #6
(08-24-2016, 06:21 AM)phyrrus9 Wrote:
(08-23-2016, 06:21 PM)insidious15 Wrote: Be careful when you say programming is easy. I tutored Comp Sci for a while and to some it comes easy but most people know shitall about programming even after applying themselves for a semester. In fact, I'd say most don't know/can't program for shit (talking about my exp with college students) if they are not a Comp Sci major. It takes a certain patience and interest.
other than that great guide.

Maybe your tutoring was at fault? Programming in essence is just understanding structure. If you can speak any language, you can learn to program. How your brain is wired may effect which language is easier to learn, but it's fundamentally simple.

I admit, my tutoring was not the best. That, or the class was not taught in a way that the students I was tutoring would understand.
Programming is simple, following the rules of logic and discrete mathematics, although. Despite that, it requires patience and practice. Something that may be hard to come across in many people.

Football and Soccer are fundamentally simple games. Although this does not mean they are easy to excel at, many can learn the basics of these games without much effort and many do. To truly be successful, however, they require physical prowess to succeed. IE: Practice and patience. Programming, I think, is very similar. To simply learn the basics is not difficult, but to excel may be quite difficult and requires alot of both practice and patience.
[Image: pBD38Xq.png]
Email: insidious@protonmail.ch

Reply

RE: The do's and don'ts of programming #7
Thanks, pretty useful and is good for my college course coming up.
Donate to be in my siggy!
Spoiler: Donators
@Ender ♦ @Customer-chan ♦ @Diego ♦ @Logo ♦ @Bish0pQ ♦ @Altair ♦ @Botanicals

Reply

RE: The do's and don'ts of programming #8
Quote:Some languages (PHP, javascript, python, etc) allow you to declare a variable at runtime, and whenever you want. This is a neat little tool, but it isn't used as it should be. In essence, you should know [b]EXACTLY what variables you need from the start. Dynamic definitions is a scoping feature, NOT a convenience. If you have a function that does something, and you need three variables, don't define them the first time you use them, define them at the top of the function! This goes for languages like C as well (older versions actually forced this). I have been caught a few times forgetting a variable name and digging through it, it sucks, avoid it.

Could you give a python example with this. I haven't used python in a while and I just want to make sure I'm understanding what you mean. Thanks.
"If you look for the light, you can often find it. But if you look for the dark, that is all you will ever see.”


Reply

RE: The do's and don'ts of programming #9
(08-27-2016, 06:12 PM)God Wrote:
Quote:Some languages (PHP, javascript, python, etc) allow you to declare a variable at runtime, and whenever you want. This is a neat little tool, but it isn't used as it should be. In essence, you should know [b]EXACTLY what variables you need from the start. Dynamic definitions is a scoping feature, NOT a convenience. If you have a function that does something, and you need three variables, don't define them the first time you use them, define them at the top of the function! This goes for languages like C as well (older versions actually forced this). I have been caught a few times forgetting a variable name and digging through it, it sucks, avoid it.

Could you give a python example with this. I haven't used python in a while and I just want to make sure I'm understanding what you mean. Thanks.

Code:
#!/usr/bin/python

integer_variable = 5
integer_variable2 = 3
integer_result = 0     #assigned during addition routine

######################
#addition routine
######################
integer_result = integer_variable + integer_variable2

vs defining variables on the fly
Code:
#!/usr/bin/python

integer_variable = 5
integer_variable2 = 3

######################
#addition routine
######################
integer_result = integer_variable + integer_variable2     #integer_result isn't defined until the addition routine, considered bad practice by many, and will leave you open to debugging issues

[+] 1 user Likes phyrrus9's post
Reply

RE: The do's and don'ts of programming #10
(08-28-2016, 03:05 AM)phyrrus9 Wrote:
(08-27-2016, 06:12 PM)God Wrote:
Quote:Some languages (PHP, javascript, python, etc) allow you to declare a variable at runtime, and whenever you want. This is a neat little tool, but it isn't used as it should be. In essence, you should know [b]EXACTLY what variables you need from the start. Dynamic definitions is a scoping feature, NOT a convenience. If you have a function that does something, and you need three variables, don't define them the first time you use them, define them at the top of the function! This goes for languages like C as well (older versions actually forced this). I have been caught a few times forgetting a variable name and digging through it, it sucks, avoid it.

Could you give a python example with this. I haven't used python in a while and I just want to make sure I'm understanding what you mean. Thanks.

Code:
#!/usr/bin/python

integer_variable = 5
integer_variable2 = 3
integer_result = 0     #assigned during addition routine

######################
#addition routine
######################
integer_result = integer_variable + integer_variable2

vs defining variables on the fly
Code:
#!/usr/bin/python

integer_variable = 5
integer_variable2 = 3

######################
#addition routine
######################
integer_result = integer_variable + integer_variable2     #integer_result isn't defined until the addition routine, considered bad practice by many, and will leave you open to debugging issues

Thank you for clarifying. I'm pretty sure I'm guilty of this as I started with Python and I for one thought not needing to initialize variables was part of the convenience of the language.
"If you look for the light, you can often find it. But if you look for the dark, that is all you will ever see.”


Reply






Users browsing this thread: 1 Guest(s)