tags:

views:

327

answers:

6

I've seen, here and elsewhere, many questions that, to get input data, use something like this:

 ...
 printf("What's your name? ");
 scanf("%s",name);
 ...

This is very reminiscent of the old BASIC days (INPUT for those who remember it).

The majority of those questions, if not all, are from people just learning C and are homeworks or example taken from their book.

I clearly remember that when I learned C I was told that this type of question/answer style was not a good practice for getting user input. The "Right Way" was either to get parameters on the command line (argv[...]) or reading from a data file to be parsed with fgets(). When user friendliness was a must, termio and friends had to be used.

Now, I wonder if anything changed in the past years. Are people thaught to structure user interaction as a set question/answer now?

I can only see disadvantages in using the printf()/scanf() approach, the main one being the diversity of terminals (^H anyone?) that could make difficult for the user to correct mistakes.

Could anyone point me to concrete advantages of this approach?

+2  A: 

I always thought the Unix way was to accept input from stdin. That way the caller of the command can pipe input in from another command, from a file or manually.

ctford
+1. I tried explaining this to my "Java professor" and he wouldn't buy it. But he's also a Windows guy and he's into drag n' drop GUI building. So he made me redo a program to do the question and answer style. I just made it construct command line args and then pass that along to the function I already made to handle the arguments. Some people just aren't cut out to do things the right way I guess.
jonescb
+3  A: 

This structure is easy to explain and easy to learn, which is why it appears in so many introductory materials. Doing user input "the right way" in C can appear fairly daunting to a neophyte, especially when you have to deal with tokenizing and conversions.

However, I agree that it would be valuable for introductory materials to demonstrate more robust methods for handling user input.

John Bode
Ease of explanation is the only advantage I can see. But doesn't this translate to teacher's lazyness? :)
Remo.D
+1  A: 

fgets() / sscanf() or similar is the right way to accept user input.

Take what you read here and elsewhere with a (large) pinch of salt.

pmg
+1  A: 

In many cases you are probably missing the point of the exercise if you think this is important. There's a world of a difference between a homework exercise and real world programs. The purpose of such exercises is seldom, if ever, to teach user interface design; the technique you describe is generally just a simple way to obtain test input for the real exercise, and is also probably encouraged by tutors who, pressed for time require submitted code to adhere to some 'course-style' to make marking easier. 'Course-style' is seldom the same thing as 'good-practice' or 'practical style', but that is not to say that it does not serve some purpose, or even that that purpose is beneficial to the students education.

Unfortunately novices often get hung up on this stuff when it is generally irrelevant to the actual purpose of the exercise. The problem is that user input using standard library primitives is not as foolproof and some tutors seem to think.

Clifford
A: 

I agree with CTFord, that IF you're doing a command line program, then stdin is a perfectly reasonable way to deal with input.

However, now adays, the correct way is to make a window that has a text box a label and a button and blah blah blah.

I know that doesn't really answer your question, but I think my point is that that style of programming has become MUCH less prevalent, so that it doesn't really matter what is "correct".

Brian Postow
I agree that is less prevalent, but there are cases where a GUI would be overkill or plainly incorrect. I would prefer that teachers and introductory books would not promote an interaction style that has no advantages over the "correct" way (that I think matters :) )
Remo.D
+1  A: 

The GNU readline library is really an excellent resource for this. Its main advantage is that it handles all the intricacies of editing, as well as letting users have their own input settings, eg Vi or Emacs mode.

This is the library bash and many other programs that accept interactive line-based data use. By using the library, you get an interface that your users will have some knowledge of how to use, plus you get all sorts of nice features without having to explicitly code support for line editing.

McPherrinM
Agreed. Can I summarizing saying that you, as a user, would prefer to have a program using readline to handle your input rather than being left on a wild terminal waiting on a scanf() ?
Remo.D