chicken soup for a programmer's soul(or the return of the inner geek)
in our project at work, there is a limit to the number of bugs(or errors for non-programmers) we can incur depending on the number of lines we coded, err, wrote for the project. right now, it's one bug per kiloline(i didn't know there was such a word) or a thousand lines of code. for this project, we have a limit of 50 bugs which means we've written 50,000 lines of code. robii jokingly reminded us with this brief line, use your bugs wisely. and as i think about it, it's true for programming as it is for life. sure, there's no quota to the mistakes you can make unless you've done something that would keep you from exercising your freedom to make choices which would range from self-inflicted injuring, maiming yourself or suicide. although i've said before that we shouldn't be afraid of making mistakes, it shouldn't be an excuse to go off and commit stupid, useless mistakes that could've been prevented in the first place if we've practiced a little more discretion and reflection, a lot of tact or patience, and little less pride and obstinacy. There are needless, useless bugs (see #2) as there are mistakes and i for one think that not only is life too brief to commit them but chances come by too infrequently to waste them.
2.) /*careful with the comments*/
there are lines in a code that aren't actually part of the program but are there as some sort of note, explanation or reminder to the programmer or the user. thus, the term, comment. all you have to do (at least in most languages) is prefix a single line with a "//" or if it's multi-line, you enclose the lines in between a pair of "/**/".anyway, i was in a rush the other day commenting out lines of code that i accidentally commented out an important line that checks for certain conditions before allowing a set of instructions to be executed. I overlooked that detail resulting to a bug that caused the system to crash, uhm, fail, at the start of the run. i've managed to fix it but another note to self, the little details count. funny but i used to accuse my ex-boyfriend about not paying attention to the little details and here i am committing the same carelessness. talk about the kettle calling a teapot black(or something to that effect). little details DO matter.
3.) divide and conquer
one of the chief concerns in programming, as far as i've observed anyway, is making sorting algorithms more efficient. it could mean reducing the space the particular alogorithm uses when it is executed or the amount of time it takes for it to complete a search. there are a couple of algorithms some of whose names do not merely sound interesting but are actually descriptive of what they do like bubble sort(the element with the least amount rises up the top of the pile, like a bubble). anyway, one particular algorithm, mergesort, works around the idea of dividing the set to be sorted into smaller and more manageable sub-pieces and then works its way up by putting back all the subdivided pieces.a while ago, i was trying to search for an excessive closing curly bracket in my code which was about a hundred lines long. it sounds easy and i thought so too but you wouldn't believe how tricky a couple of parenthesis and brackets can be. my groupmate louie noticed my agitation over my lack of success that he suggested i take out the whole block of code that i suspected to contain the problematic lines then try to add a portion of it to my code until i identify where the error is.in short, he says, divide and conquer. or as a rhyme in this recycled papelmoriti wrapper says,
life is a cinch.
yard by yard,
life is hard."
4.)to each his own algorithm
in college we had to study and eventually simulate several process management algorithms of an operating system. we all know how difficult it is trying to accomplish tasks, much less keep track of them especially when our fingers aren't even enough to count them.imagine how much tougher it'll be for your computer's os. anyway, some of them brilliant computer people, designed several techniques to manage these tasks.as far as i can remember there's the first-come, first-serve algorithm which is pretty much self-explanatory. then there's a shortest-job-first algorithm which is also pretty much descriptive and the round-robin algorithm wherein a time limit common for all tasks and when it expires, the next task is executed for the same amount of time, and so on until all tasks are done. in short, every task gets the same amount of time(or less). there are other algorithms that are a combination or modified version of the previous ones. i don't remember the others but my point is, inasmuch as an os has a plethora of options for its tasks, so do we. the challenge is finding one that works and works best for us. different strokes for different folks.go find your best stroke.
(to be continued...)