Jump to content

Photo

Programming Theory: A Primer


  • Please log in to reply
7 replies to this topic

#1 K_N

K_N

    Megabyte

  • Members
  • 576 posts
  • LocationPhoenix

Posted 29 January 2012 - 04:59 PM

I figure we'll have a lot of amateur programmers and hobbyists here, so why not have a primer/refresher on the more basic, overarching concepts of programming.

Simplicity:
To begin with, computers were created to make things easier. First, to do math that took humans far too long. As they've evolved, they've taken over assembly, production and all sorts of things that humans are slow and inefficient at. All programming should follow this logic as well - make it simple.

Reductivism can be applied to all levels of programming; for instance - when you first design your program's purpose and functions, ask yourself: (Am I making this task easier to do for the user? How can I make it easier?). If your program makes things harder or more exasperating, who would want to use it?

At the lower level, you apply it to your code itself. If you find yourself writing a Java class with thousands of lines of code, chances are there's functions of that class that can be put in others of their own, to make your code simpler. If you're dealing with boolean logic, say in PHP, and you have an if statement with 10 different "else" lines, couldn't you make that a switch? Catching little things like that make you a good programmer. Remember, when the same logic is executed over and over by a computer, a tiny bit of extra processing time adds up quickly.

I'm reminded of something I was told in /r/learnprogramming:

Many people think that being able to write clever, difficult to understand, convoluted programs makes them better programmers. In fact, the opposite is true: writing an easy to understand, simple looking program is much harder, and also much better.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupery




Naming Conventions:
Your code should make sense. This is something even well paid programmers have trouble with.

Name your variables what they store - $derp or int herp can lead you to make a lot more mistakes when computing them than $totalInterest or int accountNumber. The same with functions! Imagine you're coming back through your code several weeks later: what's going to help you understand the point of a code block better: the function ab() or the function convertToCompoundInterest()? Obviously, the extra second it takes to type out the name instantly tells you that the function converts the input to compound interest.

The above also explains why /* commenting */ is important. Comments can detail a function, a block of code that looks out of place, things to do in the future, or even a kludge that you plan to replace with good code later.

Commenting is also very important as a professional programmer. A great deal of work out there is dealing with someone else's code, or writing code that someone else has to deal with. Sure, your code may be obvious to you but will someone else's code be that obvious? Someone with different naming styles, different ideas of what parts of a program come first? Probably not. So it helps a lot to have explanatory comments along the way.


---

These are only some basics that will help you along the way - there's much more to being a good programmer, but keeping what I've said here in mind will keep you above a large heap of skiddies and scrubs out there.

Feel free to ask questions or add opinions below.

Rumors of my demise have been greatly exaggerated.


#2 SpleenBeGone

SpleenBeGone

    Deer Leader of the Goriest Revolution

  • Administrators
  • 14,951 posts
  • LocationHouston

Posted 29 January 2012 - 05:04 PM

I really wish more people would follow this. I'm not much of a programmer, but I do a lot of work with code that has already been built by someone else, especially PHP. It's terrible when you have thousands of lines and not a single comment.
nmjUGDL.jpg

#3 K_N

K_N

    Megabyte

  • Members
  • 576 posts
  • LocationPhoenix

Posted 29 January 2012 - 05:27 PM

To that effect, it's also extremely annoying to have engines with no API. If you're going to write code for other people to use, INCLUDE THE FUNCTIONS THEY NEED TO INTERFACE WITH IT. Don't just expect them to learn every facet of your code and usurp functions!

Rumors of my demise have been greatly exaggerated.


#4 SpleenBeGone

SpleenBeGone

    Deer Leader of the Goriest Revolution

  • Administrators
  • 14,951 posts
  • LocationHouston

Posted 29 January 2012 - 05:28 PM

:lol: Yeah I bet that causes a lot of problems.
nmjUGDL.jpg

#5 K_N

K_N

    Megabyte

  • Members
  • 576 posts
  • LocationPhoenix

Posted 29 January 2012 - 05:32 PM

I actually ran into this with someone who wrote an alternative SQL engine for android apps, and expected people to cobble together his internal functions instead of providing direct query functions and so on.

Rumors of my demise have been greatly exaggerated.


#6 SpleenBeGone

SpleenBeGone

    Deer Leader of the Goriest Revolution

  • Administrators
  • 14,951 posts
  • LocationHouston

Posted 29 January 2012 - 05:42 PM

How'd that work out for him?
nmjUGDL.jpg

#7 K_N

K_N

    Megabyte

  • Members
  • 576 posts
  • LocationPhoenix

Posted 29 January 2012 - 05:51 PM

No one bothered using his code and he went pretty unnoticed at the entire workshop.

Rumors of my demise have been greatly exaggerated.


#8 Zashiki_Warashi

Zashiki_Warashi

    Kilobyte

  • Members
  • 235 posts

Posted 29 January 2012 - 11:40 PM

Thanks!

It has been a LONG TIME since I've programmed and I'm finally starting to get back into the swing of things to start programming again; so yeah, I'm pretty rusty.

Once again, thanks!