Showing posts with label code style. Show all posts
Showing posts with label code style. Show all posts

Tuesday, February 15, 2011

Programming Side Effects

Alright, so it's not often I actually benefit from programming classes, but every once in a while, a teacher sparks off an idea. Today that idea was side effects! This is a concept related to style and modularity, as well as a little bit of math.

Traditionally in math, when you call a function, you get a value back, f(x) = y. Going further, these results should be communicative, f(x) + g(x) = y and g(x) + f(x) = y. In programming however, this is not the case. All sorts of additional values can come in and contaminate the purity of the math based idea of functions, global variables like time and random seeds, and nearby variables that track the internal state of a class. All of these affecting values are called "Side Effects".

Here's a quick example:

#include <stdio.h>

int a = 0;

int Func1()
{
 a += 2;
 return a;
}
int Func2()
{
 a *= 4;
 return a;
}

int main()
{
 printf("%d\n", Func1() + Func2() );
 printf("%d\n", Func2() + Func1() );
}

In this case, you can easily see the side effect variable 'a', which completely destroys the predictability of the code. The problem is, this functionality is incredibly important to larger more complicated programs, which is why large amounts of effort is expended to do such things safely. This results in properties, get/set methods, and all manner of other things.

So it's something to think about when coding and to avoid if you can. It may even be a good thing to mark them down and keep track of in the comment docs, so you know which functions are less likely to be causing issues.

Just some food for thought =D

Friday, July 17, 2009

Programming Style


So here are a few things I do when I'm coding, that I find makes it easier to get things done. Since I code in C#, the Visual Studio provides me with a truly extraordinary intellisense, which not all languages receive. So given this, there are a couple of things that I do that makes typing a fair bit easier for me.


Prefixes:

While you might consider prefixes to be pretty old-school, and far out of style, I like to prefix a lot of my variables to group them together in the intellisense. This can make it particularly handy if you've forgotten what your variable is called.

For example, I always prefix my parameter list variables with 'a' (stands for Argument)





To get this to work properly, it also helps to remove any unused 'using' statements at the top of your file.

I've also read a few books on code style, and many suggest dropping the prefix, simply because your eyes skip over it anyhow. I find this to be true, but also part of the reason why I use it. The prefix is not so much for your eyes as it is for your fingers. I also find it to be helpful for avoiding name collisions, also evident in the example.

Curly Braces:

I never ever end my lines with a curly brace. I see so many Java developers that do this, and it bugs the heck out of me. The reasoning behind it is solid: to save on vertical space. But the cost for that saves comes a bit high to me.

In order to save that space, you have to sacrifice the visual indication of a new zone, and you cram your code together far more. Space is something that gives your eyes room to breath, and lets you group pieces of code together. Rarely is the 'if' condition directly essential to the following line of code, so they really shouldn't be together anyhow.

In the case where it were, a better solution would be to do something like this:

if (condition == true)
{ Code.run();

Here you retain the visual indication for the body of the statement, and you also save the space you so desired. While I have toyed with using this stlye throughout my code, I never have, seeing as my IDE has quite dissagreed with me about it.

But, empty spaces are just as important as full ones :)

Naming Conventions:

I once read in a book that comments should be avoided. I was quite stunned and appalled when I first read this statement, as I commented my code a fair bit at that point, and was quite pleased with it. However, after giving it much thought, I decided that the statement had been misphrased... A good coder should not need to write comments.

Now that, I can agree with. Be verbose! Make your variable names as descriptive as they need to be. With the rise of such incredible intellisense as we have now, why do we ever need to worry about typing the whole variable name more than once? A descriptive name can give so much more mreaning than an obscurely placed comment.

Another thing to do... Keep your methods short. The shorter they are, the better their names get, and the easier your code is to read. The measuring stick used to be the size of your screen, but what with a monitor running at 1080p? That's a large method... 8-10 lines is a bit of a better rule.


Now, that last rule... 8-10 lines? I need to work on that one :)