Postmortem: stacksToVCF
Now that the stacksToVCF program is, for the most part, complete, I wanted to do a brief postmortem on it.
What worked:
What didn't work:
"
Here are a few things that I would do differently:
1) Command line error outputs: You have 3 different error outputs. I would only have one. When any part of the command line is incorrect, I would just output the "manual". The manual just basically says: Here's how to use this program...
2) for (int i = 0; ...)
While this is perfectly correct for C++, it's not acceptable by most C compilers. And it offers no advantage over the traditional C way. So I would do:
main (...)
{
int i;
...
for (i = 0; ...)
...
}
3) C++ allows variable redefinition. I don't see it as an advantage. That feature can lead to very confusing (and thus hard to debug) code. While you are not doing it now, it could become a habit later on: You declare new variables inside your code and just before they are needed:
int outputCounter = 0;
int errCounter = 0;
I like the following better:
routine (...)
{
// All variables declared here
// Code begins here. No variable definition from this point on
}
"
What worked:
- External library: It was the first time I've used a library outside of the C++ Standard Library. I used mysql++, which is a wrapper for the MySQL C API. Using an external library was much easier than I had thought it would be, probably thanks to the excellent documentation for mysql++.
- Object Oriented Programming: It was the first time I've tried to organize and implement a program using classes. I had an easier time thinking about the code with this abstraction in place.
- C++: I had considered doing this in Python, but since it was a slightly bigger project than my typical throw away code, I went with C++ because I believe it forces me to be less sloppy (that's not to say that I write clean code in C++). With Python, I almost never think about memory or data structures, and I like that C/C++ are a little less forgiving. For example, I had an issue where I was getting really strange behavior using sprintf(); it was changing the value of a different variable. As it turns out, it was because I was accessing memory outside of the bounds of the array I was interested in, and this was causing undefined behavior. I think programming in C/C++ is much more instructive than Python (although I think it's tough to beat Python in terms of time to write).
- vim: I used gvim as an IDE, using the c.vim plugin. For my purposes, it worked great, and I hope to get better with it.
- Git: Using git and GitHub were useful and relatively painless. I hope to get more familiar with these tools.
What didn't work:
- My understanding of C/C++: I definitely need to work on my understanding of the relationship between pointers, pointers to arrays and strings; i.e. char * , char array[], and std::string. This caused me a bit of trouble, and I eventually got lazy and went with std::string even though that required a bit of type conversion between the mysqlpp::String to the std::string (mysqlpp::String has an automatic type conversion to a const char * , but not to a std::string).
"
Here are a few things that I would do differently:
1) Command line error outputs: You have 3 different error outputs. I would only have one. When any part of the command line is incorrect, I would just output the "manual". The manual just basically says: Here's how to use this program...
2) for (int i = 0; ...)
While this is perfectly correct for C++, it's not acceptable by most C compilers. And it offers no advantage over the traditional C way. So I would do:
main (...)
{
int i;
...
for (i = 0; ...)
...
}
3) C++ allows variable redefinition. I don't see it as an advantage. That feature can lead to very confusing (and thus hard to debug) code. While you are not doing it now, it could become a habit later on: You declare new variables inside your code and just before they are needed:
int outputCounter = 0;
int errCounter = 0;
I like the following better:
routine (...)
{
// All variables declared here
// Code begins here. No variable definition from this point on
}
"
Comments
Post a Comment