Has anyone tried...
notecard programming?
It's supposed to be like:
1. Write a raher simple code in the computer.
2. Grab an index card (3" X 5").
3. Write your code on the index card (use the back if needed).
If your code is longer than what fits on the card, it is inefficient.
Do many people use it?
It's supposed to be like:
1. Write a raher simple code in the computer.
2. Grab an index card (3" X 5").
3. Write your code on the index card (use the back if needed).
If your code is longer than what fits on the card, it is inefficient.
Do many people use it?
Never heard of it :P
I am very much an OO-centric developer, and that would definitely not fit in the OO-design world. :)
I am very much an OO-centric developer, and that would definitely not fit in the OO-design world. :)
closed account (z05DSL3A)
I thought that you were heading toward Class Responsibility Collaborator (CRC cards)[1]; but no, I never heard of it. About the closest I have heard was a lecturer that said a function should be able to be displayed on a single screen.
Dose that mean your code is more efficient if you have smaller handwriting? ;0)
[1] http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card
| If your code is longer than what fits on the card, it is inefficient. |
Dose that mean your code is more efficient if you have smaller handwriting? ;0)
[1] http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card
Last edited on
It is one of those "one size fits all" rules. See what the C++FAQ-Lite has to say about such thinking:
http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.2
While it is generally true that when individual functions start becoming longer than a screenful or two that some consideration should be given to the possibility of breaking it into smaller functions --that is simply not the case in every situation.
Write your code with the algorithm design in mind, and don't fill your brain up with stupid ancillary measurements. Real programmers don't believe that crap, and neither should you.
I can waste all kinds of efficiency in just a couple lines of code. (And that is where bottlenecks usually occur, too.)
Hope this helps.
http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.2
While it is generally true that when individual functions start becoming longer than a screenful or two that some consideration should be given to the possibility of breaking it into smaller functions --that is simply not the case in every situation.
Write your code with the algorithm design in mind, and don't fill your brain up with stupid ancillary measurements. Real programmers don't believe that crap, and neither should you.
I can waste all kinds of efficiency in just a couple lines of code. (And that is where bottlenecks usually occur, too.)
Hope this helps.
Last edited on
Just to add to what is already written, the 'Keep functions to a single screen' thing is a 'rule of thumb' - it's a guideline not a rule.
By keeping functions shorter, they are more likely to be just doing one thing - which is generaly a good thing - the function names can be more specific, it's easier to read the function code and the calling code, etc.
If you find you have long sprawling function that you have to scroll several screens to read, and which has a meaningful name of 'printAndSaveTheOutputTheInitialiseForTheNextEntry()' then you should think about splitting it up:-)
By keeping functions shorter, they are more likely to be just doing one thing - which is generaly a good thing - the function names can be more specific, it's easier to read the function code and the calling code, etc.
If you find you have long sprawling function that you have to scroll several screens to read, and which has a meaningful name of 'printAndSaveTheOutputTheInitialiseForTheNextEntry()' then you should think about splitting it up:-)
Counter examples aren't all that uncommon either.
When I was first learning C I obtained and (heavily) modified Steven A. Bennett's famous GIF LZW decoder. The main routine is about a hundred and twenty lines long --with commentary it is nearly 200 lines long. But it is blazingly fast and gracefully handles every conceivable error.
:-]
When I was first learning C I obtained and (heavily) modified Steven A. Bennett's famous GIF LZW decoder. The main routine is about a hundred and twenty lines long --with commentary it is nearly 200 lines long. But it is blazingly fast and gracefully handles every conceivable error.
:-]
@ Duoas: ROFL
I'veheard of CRC too and immediately thought of this, but i can see that it would be a good thing to do to create function libraries etc becase you could organise your hard copies in some type of order and just pull it out later. you could have a note on the bottom about where it is coded so it doesn't take you hours to find the code too :)
| Dose that mean your code is more efficient if you have smaller handwriting? ;0) |
I'veheard of CRC too and immediately thought of this, but i can see that it would be a good thing to do to create function libraries etc becase you could organise your hard copies in some type of order and just pull it out later. you could have a note on the bottom about where it is coded so it doesn't take you hours to find the code too :)
Topic archived. No new replies allowed.