Wednesday, December 17, 2008

Source Code Privacy

Letting someone see your source code is a very private thing. Usually there are a million things that could have been done better, but your program works and that gives you a great deal of satisfaction. If your project is large enough, your source code will always have some less-than-ideal software engineering concepts like global variables.

MTG Forge has global variables and hard coded card names, but it works. People need to realize that software concepts like global variables are NOT always bad, generally they are bad. Global variables represent a trade-off and most of the time they should be avoided. Sometimes global variables help you overcome some obstacles like, “I don’t know how else to program this.” That previous statement is why I used global variables.

Source code is also very private because you like the way you split up a string, even though there are different ways to do it. You like the order of the arguments and you like the architecture that you thought of. Source code is almost a diary of your thoughts, and most people don’t post their diaries to the internet, although I do know that blogs exist. Source code almost invites criticism from other programmers.

Version 2 doesn't have any global variables because they tend to attract errors. Version 1 used global variables as an easy way to "get and see everything." The problem with global variables in version 1 is that there isn't an easy way to reset everything and start a new game, that is why sometimes you have 7 or 8 cards in your opening hand.


Nxwtypx said...

I beg to differ - I usually happily show the code of Macros I've created for work to anyone interested enough to see it.

As to global variables, perhaps my operations are too small (my biggest VBA macro hovering at a thousand lines), but I use them all the time; as to resetting them, I just have a big long subroutine to do it.

Gando the Wandering Fool said...

@Nxwtypx: Macro design follows a bit of a different protocal in terms of what is good and what isnt good practice. In scripting languages there is no compilation so you can make changes to the source whenever needed and anyone who has the script(macro) can make these changes. With Coding once the code has become an object only those who have access to the source can make the changes. Also 1k lines is a huge amount of code for a macro which normally has a few sharply focused tasks, but it is absolutely tiny for a program with serious functionality. If you looked at the source for Word(or Excel) For Windows that uses that macro youd find probably more like half a million lines of code. :) Maybe not since its been refined over a few decades but still it is more likely to much larger. With that much code a global variable can make mush of what you've written.:)

@Forge Yes it can be a private thing but sharing source is akin to collaboration. It gives other people a chance to help you fix things you didn't know how to fix. And maybe insight into how to refactor such code in the future. Also in the defense of global variable use. They exist for a reason besides just legacy. They should be used with great caution in any complex coding endeavor but they may indeed be the only GOOD way of accomplishing certain things. I prefer to put such data into Objects that are given global scope but I understand that Java is a bit funky with Scope issues. Also if you are uncomfortable with people viewing your source that tells me you think it is wrong/unworthy and that is a poor attitude. EVERYONE writes bad code sometimes. Your code is probably at its core principle just fine and stands as a proof of concept. That's no small thing.

Forge said...

I'll take "proof of concept", in other words MTG Forge actually works and that was my final goal.