Olin Lathrop wrote:
>> The students have invested a lot of time in developing the project,
>> and were really proud of it, but the code was like a roll of toilet
>> paper, with some functions spanning multiple pages. If they followed
>> the simple rule that functions longer than 10 lines are suspect, and
>> should be considered for refactoring, the code would have been much
>> easier (and fun-ner) to develop, debug, and maintain.
>
> I disagree.  They are students just getting into programming.

Yes, sadly. After three and a half years of Computer Engineering, and just 
one semester away from graduating with their BS degrees.


> At this point
> it is more important that they get something done in a way that makes 
> sense
> to them.

Since when are you an advocate of newbie rights? :)

What you said above doesn't make sense -- why not show the students that 
there is a better way? Not "impose" anything on them, but show them the 
available options, and explain the pros and cons of different programming 
styles.

I'm actually thinking about getting in touch with the Dean to pitch the idea 
of offering seminars for students who are interested. Our selfish 
self-interest in this, is finding and snatching the best and the brightest, 
before Microchip and Freescale have a chance to get them. :)


> If you impose a bunch of rules, especially ones off the deep end
> like 10 line subroutines, it will just make the task seem overwhelming to
> them.

I think you have a very narrow and distorted vision of what I'm talking 
about. I think if you just try to understand what I'm talking about, you'll 
see that I have never argued for arbitrarily splitting up functions based on 
the line count (that would be ridiculous). Let me ask you several very 
relevant questions:

1. Do you currently develop software in C? The feeling I get from your posts 
(and other people's comments) is that you prefer assembly (which is a very 
different beast).

2. What is the average size of your functions? What is the size of the 
shortest one? Longest one?

Please don't ignore these questions, lest we continue down the path of vague 
abstractions, baseless accusations, and strawmen.


> Now that they are done with the project it is a good time to go over the
> code with them and suggest improvements.

Too late, they're done. An iterative approach would have worked best, but if 
that's not an option, a short presentation on available tools and 
methodologes would be far better than trying to pick up the pieces after the 
fact (when all the motivation is removed).


> Start by finding sections of code
> that are repeated and put them into subroutines.  The logical structure is
> far more important than the length of the subroutines.  And of course get
> them used to the idea of documenting the code, but go easy knowing they 
> will
> think it's silly and rebell.

"Small" and "cohesive" go hand in hand. A lot of times, you don't realize 
that "code is repeated" until you put it in its own subroutine, and find 
yourself calling it from other subroutines.


Vitaliy

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist