imagine you just finished writing 2000 lines of code. now to see if it works... nope, not working. now what? this kind of hopeless situation is exactly what unit testing and cxxtest are used to prevent!
unit testing is the practice of testing if each tiny component of the program works correctly as soon as it's built/linked together with other parts into a bigger unit. this is a practice recommended exponentially more with the size of the program. Why? Because YOU WILL NOT GET EVERYTHING RIGHT THE FIRST TIME AROUND! Then the butterfly effect multiplies it many times over depending how deep in your program it is. these tend to be horrible and hard to find errors that unit testing saves you from.
unit testing is very useful, but constantly testing every single piece of code is a pain. this is where cxxtest comes in. cxxtest is a tool that helps automate testing. this allows you to test more and easily, thereby making unit testing more doable.
in conclusion, unit testing is necessary and cxxtest makes it workable. this can save you a great deal of work, headache and time. i know it did me.
Monday, November 7, 2011
Monday, October 31, 2011
For thous of you who do not know, source control is a way to manage file changes on a program being worked on by multiple people at once. Version control is keeping a copy of the older versions of the program in case you want to backtrack. Source control is a related tool that helps with the merging of shared code edited at the same time by making the process of integrating contradictory changes relatively painless.
A common tool for both is subversion. (yes, i know, it sounds like someone overthrowing the government or something, but not that subversion) Subversion is a powerful and useful tool that can make the task of working with others on a large program much easier. Especially if the group is too busy to be able to always meet, or if some prefer working from home. This can be one of the most frustrating parts of group programing. Especially considering that not all computer programmers have an exactly outgoing and social personality...
One of the biggest problems I personally found when working with subversion, was the terminal. Subversion, or svn, is generally accessed directly and only from the terminal. Especially to an amateur like i was, having to work with an abstract interface like the terminal to access, send and retrieve the files in the subversion repository, can be quite a challenge and can easily develope into disdain for the entire system. Though i freely admitted that svn could be useful, the terminal interface made it so cumbersome to use, that even with the many a shortcut we learned for it, using svn still involved a considerable amount of PAIN.
To solve this problem, for thous who are not familiar with the terminal and want to use svn quickly, especially, I recommend a program called tortoise. It has a simple and familiar windows interface that wraps svn in a usable format, while keeping most of the functions the same. And if ever more versatility is needed, THEN you can use the terminal.
Tortoise also takes care of the rather annoying problem of always typing -m "~~~" to enter in the required comments for your submission lest you get the mystery screen of how-the-hell-do-i-get-out-of-here by providing a comment box. this fixes the annoyance of using svn while keeping all of it's power in tact.
As for whether or not to use svn, unless you can get it done in about an hour, yes. I'd recommend it even for small projects and working alone. Mainly due to the revision control. That's always nice. But also, i can't really think of a reason not to use it. Can you?
A common tool for both is subversion. (yes, i know, it sounds like someone overthrowing the government or something, but not that subversion) Subversion is a powerful and useful tool that can make the task of working with others on a large program much easier. Especially if the group is too busy to be able to always meet, or if some prefer working from home. This can be one of the most frustrating parts of group programing. Especially considering that not all computer programmers have an exactly outgoing and social personality...
One of the biggest problems I personally found when working with subversion, was the terminal. Subversion, or svn, is generally accessed directly and only from the terminal. Especially to an amateur like i was, having to work with an abstract interface like the terminal to access, send and retrieve the files in the subversion repository, can be quite a challenge and can easily develope into disdain for the entire system. Though i freely admitted that svn could be useful, the terminal interface made it so cumbersome to use, that even with the many a shortcut we learned for it, using svn still involved a considerable amount of PAIN.
To solve this problem, for thous who are not familiar with the terminal and want to use svn quickly, especially, I recommend a program called tortoise. It has a simple and familiar windows interface that wraps svn in a usable format, while keeping most of the functions the same. And if ever more versatility is needed, THEN you can use the terminal.
Tortoise also takes care of the rather annoying problem of always typing -m "~~~" to enter in the required comments for your submission lest you get the mystery screen of how-the-hell-do-i-get-out-of-here by providing a comment box. this fixes the annoyance of using svn while keeping all of it's power in tact.
As for whether or not to use svn, unless you can get it done in about an hour, yes. I'd recommend it even for small projects and working alone. Mainly due to the revision control. That's always nice. But also, i can't really think of a reason not to use it. Can you?
Tuesday, October 11, 2011
blog assingment 2
i decided to write about the advantages rather then disadvantages of team programing. i haven't really found any disadvantages to team programing that subversion won't deal with satisfactorily. the only foreseeable problem is that both partners would try to work on the same code with two different approaches.
as for the advantages, it's always better to work in teams. the golden rule of computer programing is 'if you don't know something, the guy on the right probably does', and just having another pair of eyes on your code can help find errors that to the author are no short of baffling. not to mention that you don't have to do the work that your partner does.
i am assuming that the partner is halfway competent here...
the partners can also work together by focusing on what each does best, like logic, syntax, testing, debugging and bringing the chips and drinks, all important aspects of coding and rarely all mastered by a single person. also, for something like the logic of the program, another person may have a different and perhaps better idea. even a novice programmer can help improve the program just by sharing a different look on the logic with the team.
a program that would be a horror to do alone, even with a single partner, suddenly becomes much easier.
as for the advantages, it's always better to work in teams. the golden rule of computer programing is 'if you don't know something, the guy on the right probably does', and just having another pair of eyes on your code can help find errors that to the author are no short of baffling. not to mention that you don't have to do the work that your partner does.
i am assuming that the partner is halfway competent here...
the partners can also work together by focusing on what each does best, like logic, syntax, testing, debugging and bringing the chips and drinks, all important aspects of coding and rarely all mastered by a single person. also, for something like the logic of the program, another person may have a different and perhaps better idea. even a novice programmer can help improve the program just by sharing a different look on the logic with the team.
a program that would be a horror to do alone, even with a single partner, suddenly becomes much easier.
Tuesday, September 20, 2011
i'm not at all sure what i'm 'good' at, but loops and understandable code seem fairly easy.
i tend to get how to make my loops do what i want them to. it's the functions they use that can be a problem... (like fprintf) I don't usually have problems with the logic, just the occasional one off error. i don't tend to have trouble with this so i guess i know it.
Making my code understandable shouldn't be too hard ether, i just need the comments to become a habit. this isn't hard. i'm doing it already. ...though it does get cluttered occasionally.
i need to get better with hierarchy, the overall design of the code. just viewing the code as a whole and planning it out from the start.
i'm okay with tests i guess, but have no clue about debuggers. my only experience with debuggers is the bomb lab, and i really doubt i could ever use one in a real life situation. this is one thing i need to get out of this class.
i tend to get how to make my loops do what i want them to. it's the functions they use that can be a problem... (like fprintf) I don't usually have problems with the logic, just the occasional one off error. i don't tend to have trouble with this so i guess i know it.
Making my code understandable shouldn't be too hard ether, i just need the comments to become a habit. this isn't hard. i'm doing it already. ...though it does get cluttered occasionally.
i need to get better with hierarchy, the overall design of the code. just viewing the code as a whole and planning it out from the start.
i'm okay with tests i guess, but have no clue about debuggers. my only experience with debuggers is the bomb lab, and i really doubt i could ever use one in a real life situation. this is one thing i need to get out of this class.
Subscribe to:
Posts (Atom)
