An interesting point ...

... started by DavidW on the C and C++ Programmers forum

Page 1 of 1

2 Replies - 573 Views - Last Post: 08 February 2010 - 04:36 AM

#1 Martyn.Rae  Icon User is offline

  • The programming dinosaur
  • member icon

Reputation: 540
  • View blog
  • Posts: 1,406
  • Joined: 22-August 09

An interesting point ...

Posted 08 February 2010 - 01:10 AM

in Helping C students ...

One of the techniques I have sucessfully used in the past has been to try to limit the amount of code contained in any one function or procedure. This approach gives rise to a lot of small functions, many of which may only ever be used once. Does that help readability and/or maintainability is the question? I am not talking about monolithic coding priciples here.

Perhaps an example of reading a file. Would you write (in pseudo code)

process_file(string filename) {
  open file
  if file not open return
  while not end_of_file {
     read file
     /* process file contents here */
  }
  close file
  return
}



or would you write

process_file_content(stuff read) {
     /* process file contents here */
}

process_file_content(steam file_stream) {
  while not end_of_file {
     read file
     process_file_content(stuff read);
  }
}

process_file(string filename) {
  open file
  if file not open return false
  process_file_content(stream)
  close file
  return true
}




Any thoughts or views?

Is This A Good Question/Topic? 0
  • +

Replies To: An interesting point ...

#2 NickDMax  Icon User is offline

  • Can grep dead trees!
  • member icon

Reputation: 2250
  • View blog
  • Posts: 9,245
  • Joined: 18-February 07

Re: An interesting point ...

Posted 08 February 2010 - 01:24 AM

Well generally speaking I like to try to keep what a function does to a minimum. The rule of thumb being "a function should do one thing" -- however I almost never end up with a function that does only 1 thing -- but generally everything that a function does is related.

So for example I don't mix user interaction with a function that reads the contents of a file. Separation of concerns and all.

In general I think having many small functions is far better than a few larger ones. Generally smaller functions are more abstract and more useful when the program expands.

I like to look at it this way: I like to write API's -- if I have a data file, I like to make a data file API for it. All the functions that I think someone using that data file might find neat to have regardless of what the exact needs of the this particular program are. This way the functions generally maximize reusability. in OOP I like to write "complete" classes. That is I like my classes to have a full interface even if the program only requires a subset of those members.

looking at your example above -- often I like to keep file input abstract so that I can test from stdin/stdout until I know the function is working and then switch it to the file. So I generally *would* break things out that way.
Was This Post Helpful? 2
  • +
  • -

#3 janotte  Icon User is offline

  • code > sword
  • member icon

Reputation: 990
  • View blog
  • Posts: 5,141
  • Joined: 28-September 06

Re: An interesting point ...

Posted 08 February 2010 - 04:36 AM

Especially for a student I would suggest they err on the side of too many functions rather than too few.

The more experience in passing variables and all that good stuff the better.

Getting students to see code as a series of chunks that each do something useful tends to avoid the "magic happens here" steps that you often see in a new programmer's spaghetti code.

Whether this is a style that they will use when doing 'real' work is another question but that's a problem they can deal with when they get there.

Encouraging extensive (even excessive) decomposition amongst students and newbies is an approach I would also very much support.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1