Final Refractoring Thoughts

Refractoring is nice tool to use, I probably won't use it constantly like I would unit tests but it really does help to clean up code.  Like the other day I ended up writing about 30 if statements in a row for one particular attribute that I was working on.  It ended up being about 200 lines for all of it and would only return a single value back.  I then had to do this two more times for 2 different attributes.  It made the code look terrible and I had no idea where one thing started and the other stopped.  So I used extract method on all three of those things and shoved it into a new file to hold it.  Then again I did extract method on them and then put all of the if statements related to one attribute in its own method.   Stuff like this there really isn't a big deal.  It's more of a stylistic thing and it does help make hard to follow code look way better.  Doing stuff like this doesn't really have an performance gains or hurts the performance of the application so it's not a big deal.

On the other hand, performance is a big deal.  I do believe that if you use extract method several times with small amounts of code in it over a large block of code it hurts performance by a small amount.  But when this code is called constantly and the application depends on it running super fast everything slows down significantly.  There are times when OOP is critical to be used but having ugly code that runs in 0.0000003 seconds compared to 0.01 seconds and it is being called over a billion times, I'd much rather prefer the horrifying looking code than something that is amazing looking but takes forever.  I'd much rather have Windows move files in less than a minute compared to an hour.

Job security is one of the other things that comes to mind.  If you write code that no one else can understand, you are less likely to be fired.  If you have something that looks like it is summing up some data but in reality is just sorting that data and the comments make zero sense, then that is job security.  It doesn't mean that if you write horrible looking code constantly, that could easily be written very nicely, is a good idea.  It just means that if there is some function that ties the whole system together and you are the only one who knows how it works and where to add/remove things that is pretty good.

The book on refractoring does have some really useful ideas for one to use after they have written the code or having to make changes to existing code later.  I know for sure I won't be writing code and then spontaneously decide to "Replace Type Code with State/Strategy".  I'd much rather have the code working perfectly first then clean it up.

This is the last CS 373 blog entry I'm going to write.  So to any hardcore followers, you should know where to find me on the internet.

Pro/Cons of Python

This is somewhat of a recap of what I have learned about Python this semester and what I like about it and what I hate about it.

Likes:

Generators:  Are super awesome.  They remove some of the trouble of having to keep track of an array or something that is iterable and then keep track of which spot you are at.  Instead with a generator, all you need to do is call next() and you get the next thing.  This is easily one of my most favorite things in python.

List Operations:  with stuff like [0: 5] it makes getting a sub array out of an array easy to do.  With it being able to start at the end and then work backwards is great as well.  Just to get the last element, using arr.length()-1 as the index instead makes it somewhat more readable and easier to do.

Print:  Just saying print "something"  instead of System.out.println("something");  is so much better just because it requires less typing.  And really the whole "System.out" part I hate typing because of its redundancy.

Dynamic Typing:  s="A string" I know s is a string, why should I have to type String s = "A string";  And then if I am done with s being used I could do s=67/3.  

Hates:

Dynamically Typed:  I absolutely hate it how if in a method one of its parameters is an object "A" and what is actually needed is an object "B" and then when it is used DURING RUNTIME we get the error.  This actually makes things more difficult to figure out what is going on  during runtime to pinpoint when "A" is actually being passed in.  And it could be at the end of the program making me retrace every line of code.

Indention:  I hate this.  While it seems nice to do after a while  I lose track of how the code flows and when if statements end or functions end.  I really like the enforced indentation but without nice "{" "}" I can't tell the difference between some lines of code and when to debug things.

Arrays:  I don't know why I can't create an array with a set size.  I hate having to create a while loop and then iterate over it appending useless data to the array just to get the array into a desirable size.  Which makes me hate it when I'm going through the array after finally using it and I hit one of the "dummy data" indexes and then python either: Uses that data and screws things up. Or: Treats it as an object and then throws me an error and then screw things up.

For Loops:  Where are they?  Sometimes I need to be able to iterate over something with a size that changes and using a while loop is just not good enough.  I hate having to create a lcv and setting it to 0 before the execution of the while loop and then in the end I always forget to increment/decrement it.

So those are some nice rants about how much I have enjoyed Python and how much I despise Python.  I really would not suggest using Python in a large scale project.  It makes a really well developed script but sometimes debugging things in it seems too hard to do in a large project where the complexity in increased 10000x over.