<p>This answer comes from experience teaching C to students that have about 2 years of programming experience in Python and no exposure to low-level programming. I teach an Operating Systems-like course and students take introductory C lessons before the main course.</p>
<hr />
<p>For C begginers strings are hard. Although the concept seems rather easy, students struggle with the differences between '0' and the number 0 and with the whole &quot;we represent characters as numbers&quot; thing. So, for many students coding <code>atoi</code> is a challenge at first. Expressions such as such as <code>str[i] - '0'</code> are not obvious at all and things like comparing characters make no sense (<code>str[i] &gt;= '0' &amp;&amp; str[i] &lt;= '9'</code>). Even 'a' and 'A' being different sometimes confuse students.</p>
<p>A second point is that <code>argv</code> is a pointer to <code>char</code> arrays, resulting in the type <code>char *argv[]</code>. This is not ok until students are comfortable with pointers and even then a pointer to an array takes some thinking for many students. Drawing the pointers helps a lot here.</p>
<p>Taking these two points into account, we use <code>scanf/printf</code> because it allows us to have students accepting user input and showing program results right from day one. We also teach <code>fgets</code> and input/output redirection as early as possible (so at least students understand that interacting with programs in the terminal is not the norm). The main point is that <em>C</em> has strange syntax and inner workings for students that have only used Python, so taking it slow helps. Also, they do not know the use of <code>argc/argv</code> yet, so we would have to teach it as well.</p>
<p>Later in the semester, when they are more prepared, we present <code>argc/argv</code> as a way of receiving arguments <em>from another program</em>. Students by then are able to quickly understand how to use it and can write well-behaved programs.</p>
<p>So, yeah.... teaching <code>scanf/printf</code> without ever talking about proper command line programs is not a very good approach. I would even say more: teaching <em>C</em> without a connection to how <em>C</em> is actually used is not a very good approach. The connection might be weak at first, but it must be made strong at some point. Otherwise, why would we be teaching such strange language if the programs students code are much more easily done with other languages?</p>

CC BY-SA 4.0
2021-02-23T21:45:10.377Z
2021-02-23T21:57:49.677Z
2021-02-23T21:57:49.677Z
igordsm
<p>Don't teach scanf. It is dangerous and it is a huge security leak.  Use getline instead and limit input size.  Then you can use functions in stdlib.h to parse your string into the desired type.</p>

CC BY-SA 4.0
2021-02-24T23:41:23.517Z
2021-02-24T23:41:23.517Z
ncmathsadist
<p>I think that the rationale is so you don't have to introduce arrays and array notation on day 1. Typically, arrays enter into the picture at roughly the same time as loops, which would take place a few weeks or months later, depending on the pacing of your course.</p>

<p>That said, if you want to start with command line programs, it's not a huge problem to do so.  At the very, very beginning of programming, there are always a few magical incantations that students must type, but won't fully explore until later.  <code>args[0]</code> could easily be such an incantation. </p>

<p>As a side benefit to this approach, your students may have an easier time when they come to arrays, since they've already used them a bit.</p>

CC BY-SA 4.0
2019-07-18T17:21:27.820Z
I like the `incantation` term you use.
nowox
CC BY-SA 4.0
2019-07-18T20:24:20.843Z
Can't you still talk about stdin/stdout/stderr without using the argv array? I believe that scanf still just reads from stdin, so you can easily store stdin to a variable.
thesecretmaster
CC BY-SA 4.0
2019-07-19T04:45:09.517Z
@thesecretmaster: That's what Ben is saying. The OP is asking why you don't teach about argv and Ben's answer is argv is an array so it's better to focus on stdin first
slebetman
CC BY-SA 4.0
2019-07-19T13:49:32.973Z
I'ts because we didn't have it in Basic.
Michel Billaud
CC BY-SA 4.0
2019-07-19T14:47:28.400Z
You'd also have to explain the failure modes with missing arguments.
Simon Richter
CC BY-SA 4.0
2019-07-20T15:28:40.873Z
I don't even thing that `args[0]` etc is that magical. You can give it any name you want in some languages (C, C++, java, …). They don't even need to know that it is an array. And as you say, when they start arrays, they will already know ½ of it. This may be a good example of learn to read, before you learn to write. (not the learn to read code, before you learn to write code interpretation. I think both interpretation are correct.)
ctrl-alt-delor
CC BY-SA 4.0
2019-07-20T15:33:19.353Z
Having to process args in main, as another thing forcing the C++, Java, … learner away from OO. Is there another way?
ctrl-alt-delor
CC BY-SA 4.0
2019-07-18T16:13:33.380Z
2019-07-18T16:13:33.380Z
Ben I.
<p>Because everything around C language education is just utterly awful. That's really all there is to it. <code>scanf</code> should not be taught, but it is. It's rarely useful, and you can discover it on your own if you need it. <code>gets</code> should not be taught, but it is. It's not even part of the language any more for the past eight years. I say this as one of the folks (through my work on <a href="https://www.musl-libc.org/intro.html" rel="noreferrer">musl libc</a>) seriously working on the future of the C language. Education around C is utterly backwards and needs drastic rethinking.</p>

<p>No actual software people use operates in terms of prompts, much less ones that don't have any sort of line editing or navigation forward/back in the process. (OK, some masochists use <code>make config</code> still, but...) Input to real-world programs arrives via command lines (possibly files specified on command lines or provided as stdin), GUIs, sensors, input over some sort of network protocol, etc. The easiest first case to teach is the command line, and your students are going to have to learn a little bit about it anyway to invoke the compiler if they don't already know it. By starting to teach input from the command line, you <em>show students how programs they're already familiar with are doing something they do</em>, rather than giving them an example that seems forced/unnatural/foreign.</p>

<p>Others have commented that using the command line requires getting into arrays early, but you can paper over that until students are ready. I find processing input from stdin to be a good place to start too, <em>with the caveat that you use input redirection</em>. Behaviors like terminal line buffering/canonical mode are not at all intuitive to students, and detract from teaching the language. If you instead have them process input redirected from text (or binary) files, you can avoid that. Just don't use <code>scanf</code>. It's awkward, unintuitive, and often unsafe. Start with <code>getc</code>/<code>putc</code>, then <code>fgets</code> when you're ready to do some parsing.</p>

CC BY-SA 4.0
2019-07-20T12:31:46.787Z
Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/96423/discussion-on-answer-by-r-why-teach-c-using-scanf-without-talking-about-comman).
thesecretmaster
CC BY-SA 4.0
2019-07-21T05:00:46.477Z
Now that this question has pointed it out, the same thing is obviously true in assembly language.  So many Q&As about reading string inputs into buffers and so much code clutter from printing prompts first.  (Although we'd still get lots of asm questions about converting strings to integers, especially multi-digit strings.)
Peter Cordes
CC BY-SA 4.0
2019-07-21T06:06:16.827Z
@PeterCordes: Absolutely. And it's even worse if you don't have subroutines yet, and rather misleading if you use bios/syscalls in place of subroutines. I'd hesitate to each asm as a standalone language at all, preferring to teach it first with "call from C" being the way it's invoked.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2019-07-21T06:46:13.810Z
The MARS  MIPS simulator keeps things somewhat clean by providing "syscall" implementations of read integer from user-input, and of print decimal, print hex, etc.  It's very much a toy system. I think it makes command-line args accessible to modify between runs somehow, though.    For x86 Linux running natively, not in a toy simulator, probably teaching calling conventions as part of the boilerplate for running asm by calling from C would work. But it does introduce more moving parts. I can certainly see why courses don't do that, at least if they try to do asm before student's really grasp C.
Peter Cordes
CC BY-SA 4.0
2019-07-19T05:54:38.500Z
2019-07-20T12:30:25.963Z
2019-07-20T12:30:25.963Z
R.. GitHub STOP HELPING ICE
<p>Because, traditionally, programs iterate over data. See <a href="https://en.wikipedia.org/wiki/Jackson_structured_programming" rel="nofollow noreferrer">JSP</a>.</p>

<p>Admittedly, prompting the user for data is weird, however we're talking about beginners here, having them try to remember what the different fields of data they have to enter isn't the point of the exercise, and is likely to make them view interacting with computers as needlessly complicated. As a bonus, prompting for the values helps make the beginner programs self documenting - the text of the prompt is an explanation of the variable that is to be read - so this will hopefully help our novice programmers understand the simple program without introducing the complex topic of comments. </p>

<p>(I was taught it wasn't legitimate in early versions of pascal to output before input, so you couldn't prompt for input.)</p>

CC BY-SA 4.0
2019-07-19T00:17:56.793Z
Do you have a citation for your Pascal factoid? I don't remember that one.
Buffy
CC BY-SA 4.0
2019-07-19T23:07:36.120Z
good question @Buffy. It was something I was taught in '86, as having been the case but no longer was, but I took that as truth without asking for proof.
Grump
CC BY-SA 4.0
2019-07-20T17:26:45.447Z
Wasn't it something with some implementations, like: the first reads on input return the command line, unless a write is issued on output ?
Michel Billaud
CC BY-SA 4.0
2019-07-20T17:48:10.833Z
Source of a Standard Pascal compiler here : https://sourceforge.net/projects/pascalp5/
Michel Billaud
CC BY-SA 4.0
2019-07-18T23:30:12.207Z
2019-07-19T23:15:31.603Z
2019-07-19T23:15:31.603Z
Grump
<p>From my own experience tutoring young CS students, user input is actually a tricky concept.  If it were not for user input, the results of any program could be pre-compiled into nothing but its output.</p>

<p>You get one lesson from getting all the input right at the beginning, with argc/argv, but from that point on, its just the computer churning.  You get a different lesson from getting input during the execution of the program.</p>

<p>I have found that the idea of getting input from the user is surprisingly non-intuitive, given that nearly every program we interact with on a daily basis does it.  This suggests that introducing it early helps prune misconceptions about how computers work before they become a real problem.</p>

<p>Obviously not every student is the same, but a particular pattern I found occurs more than I'd like is that they can understand what a program should do when it executes but not how that actually happens.  They can look at</p>

<pre><code>BOOL x = TRUE;
if (x)
    printf("Hello\n");
else
    printf("World\n");
</code></pre>

<p>And they can intuit that the program should print "Hello", but they can't intuit how a computer can possibly do so.  As best as I can tell they figure the compiler does the "magic," and figures out which printf to use (we'll ignore optimizers for a moment).</p>

<p>However, when the values come from input, you can no longer think about the computer as a magic device which reaches the final result immediately.  You have to see that it is following steps.  We know this, but it seems many students don't grasp this at first.</p>

<p>If you have inputs coming from argv, its easier to keep this illusion going.  If you have input during the program, after the program has already done something, you have to realize what's going on quicker.  In particular, it gets you closer to the point of realizing that the input the computer asks for may vary based on previous inputs (press 1 to calculate the area of a circle, press 2 to calculate the area of a rectangle.  Depending on the next scanf/gets, the computer will ask for one additional number or two)</p>

CC BY-SA 4.0
2019-07-19T19:01:03.423Z
Could you elaborate on the unintuitive bit?  I'm always on the lookout for new cognitive traps that I haven't noticed before.
Ben I.
CC BY-SA 4.0
2019-07-19T20:01:37.550Z
@BenI. I've found that some students learn the concept of functions before they grasp the idea of execution.  They can wade their way through the code and make sense of it in their head, but they can't see that the computer wades through it also, in real time.  I find the same people tend to assume that if they compile `if(x) f(); else g();`, that the compiler figures out which of those two branches will be taken, and only captures the instructions for that branch.  They get bothered if I construct examples where it's hard to know which branch will be taken (such as when there is input)
Cort Ammon
CC BY-SA 4.0
2019-07-19T21:19:29.283Z
Fascinating!  Could you add that into your answer?  It would make the answer more valuable.
Ben I.
CC BY-SA 4.0
2019-09-17T20:07:16.150Z
As a teacher: mind blown. If your anecdote is correct, there must be some subset of students who don't grasp the concept that the code for both branches are in the executable, but one of them gets skipped over at runtime. Very interesting!
Barry Brown
CC BY-SA 4.0
2019-07-19T18:28:55.407Z
2019-07-19T21:48:58.387Z
2019-07-19T21:48:58.387Z
Cort Ammon
<p>Ultimately they need to understand both ways. Which you do first seems to be a matter of preference - or maybe just following the textbook. </p>

<p>They need to understand at some point that 'main' in C is an interface with the OS. But, since you can't teach everything at once, you have do pick the order of instruction. But teaching command line params later can give you a way to talk about "elegance" in program design. </p>

<p>Of course, the program written to accept args needs to behave properly if none (or too few) are presented. Often this defaults to prompting for data in simple programs. </p>

CC BY-SA 4.0
2019-07-21T05:07:39.717Z
You make an interesting point about validating input.  But I don't think falling back to prompting makes any sense for a simple toy program.  `if(argc < 4){ puts(USAGE); return 1;}` near the top of main.  Maybe with a specific message like "too few args" as well as the usage string.
Peter Cordes
CC BY-SA 4.0
2019-07-21T05:12:56.207Z
When it comes to parsing each arg in turn, handling errors is maybe more problematic (like a string where there should be an integer).  Prompting 1 at a time with scanf gives a different debugging experience.  One bad input can block the rest of the inputs if you don't do error checking and remove the bad token from stdin.  But a failed `atoi()` or `strtoul` just produces zero.  There's something interesting to be said there about the difference in how you validate input and report errors, and the debugging experience for total beginners.
Peter Cordes
CC BY-SA 4.0
2019-07-21T05:15:13.227Z
`atoi` is probably easier: a debugger can find that it's returning zero, and/or that you're calling it on the wrong string.  But a debugger generally can't observe the stdin I/O buffer to find out why some combo of input + format string is making all the later `scanf` calls fail.  (Same applies to debug-printf statements for people that haven't yet learned to use a debugger.)
Peter Cordes
CC BY-SA 4.0
2019-07-18T14:50:42.113Z
2019-07-18T14:50:42.113Z
Buffy
<p>Most of the books I read give examples using <code>printf</code> and <code>scanf</code>. At some point the students know perfectly how to use these two functions but they don't know about <code>stdin</code>, <code>stdout</code> and <code>argv</code>. </p>

<p>To me and according to many programming principles (e.g. KISS) a program should not interrupt the execution for prompting the user. Instead, and this is a much clever approach, the developer should learn to use the power of pipes and use the options and the arguments. </p>

<p>I think this:</p>

<pre><code>$ whatdaywas 1982 02 16
Monday
</code></pre>

<p>Is much better than: </p>

<pre><code>$ whatdaywas
Enter a year: 1982
Enter a month: 2
Enter a day: 16
It was a Monday. 
</code></pre>

<p>Is there any rationale behind this pedagogical approach?</p>

CC BY-SA 4.0
2019-07-19T09:11:32.550Z
This has nothing to do with KISS and is simply part of the Unix philosophy. Sane modern command line environments make it very easy to support both - use the argument if provided and ask the user for it if a mandatory parameter isn't given.
Voo
CC BY-SA 4.0
2019-07-20T15:24:02.940Z
(not a pedagogical answer) The 2nd program is easier to use by a naive user.
ctrl-alt-delor
CC BY-SA 4.0
2019-07-21T16:54:40.957Z
Are you teaching C as their first programming language?
Bergi
CC BY-SA 4.0
2019-07-21T16:55:59.227Z
Writing interactive programs (where user input depends on the output) doesn't work with command line arguments.
Bergi
CC BY-SA 4.0
2019-07-21T16:56:07.733Z
@Bergi Yes, first year at an engineer school
nowox
<programming><c>
Why teach C using scanf without talking about command line arguments?
# Why teach C using scanf without talking about command line arguments?

(Asked by: username_0 on 2019-07-18)

Most of the books I read give examples using printf and scanf. At some point the students know perfectly how to use these two functions but they don't know about stdin, stdout and argv. 
To me and according to many programming principles (e.g. KISS) a program should not interrupt the execution for prompting the user. Instead, and this is a much clever approach, the developer should learn to use the power of pipes and use the options and the arguments. 
I think this:
$ whatdaywas 1982 02 16
Monday

Is much better than: 
$ whatdaywas
Enter a year: 1982
Enter a month: 2
Enter a day: 16
It was a Monday. 

Is there any rationale behind this pedagogical approach?

**Tags:** programming, c

> **Comments:**
> **username_1**: This has nothing to do with KISS and is simply part of the Unix philosophy. Sane modern command line environments make it very easy to support both - use the argument if provided and ask the user for it if a mandatory parameter isn't given.  
> **username_2**: (not a pedagogical answer) The 2nd program is easier to use by a naive user.  
> **username_3**: Are you teaching C as their first programming language?  
> **username_3**: Writing interactive programs (where user input depends on the output) doesn't work with command line arguments.  
> **username_0**: @username_3 Yes, first year at an engineer school  

---

## 7 answers

### Answer by username_6 on 2019-07-18. Score: 25 | Accepted answer

I think that the rationale is so you don't have to introduce arrays and array notation on day 1. Typically, arrays enter into the picture at roughly the same time as loops, which would take place a few weeks or months later, depending on the pacing of your course.

That said, if you want to start with command line programs, it's not a huge problem to do so. At the very, very beginning of programming, there are always a few magical incantations that students must type, but won't fully explore until later. `args[0]` could easily be such an incantation.

As a side benefit to this approach, your students may have an easier time when they come to arrays, since they've already used them a bit.

> **Comments:**
> **username_0**: I like the `incantation` term you use.  
> **username_7**: Can't you still talk about stdin/stdout/stderr without using the argv array? I believe that scanf still just reads from stdin, so you can easily store stdin to a variable.  
> **username_8**: @username_7: That's what Ben is saying. The OP is asking why you don't teach about argv and Ben's answer is argv is an array so it's better to focus on stdin first  
> **username_9**: I'ts because we didn't have it in Basic.  
> **username_10**: You'd also have to explain the failure modes with missing arguments.  
> **username_2**: I don't even thing that `args[0]` etc is that magical. You can give it any name you want in some languages (C, C++, java, …). They don't even need to know that it is an array. And as you say, when they start arrays, they will already know ½ of it. This may be a good example of learn to read, before you learn to write. (not the learn to read code, before you learn to write code interpretation. I think both interpretation are correct.)  
> **username_2**: Having to process args in main, as another thing forcing the C++, Java, … learner away from OO. Is there another way?  

---

### Answer by username_11 on 2019-07-19. Score: 18

Because everything around C language education is just utterly awful. That's really all there is to it. `scanf` should not be taught, but it is. It's rarely useful, and you can discover it on your own if you need it. `gets` should not be taught, but it is. It's not even part of the language any more for the past eight years. I say this as one of the folks (through my work on [musl libc](https://www.musl-libc.org/intro.html)) seriously working on the future of the C language. Education around C is utterly backwards and needs drastic rethinking.

No actual software people use operates in terms of prompts, much less ones that don't have any sort of line editing or navigation forward/back in the process. (OK, some masochists use `make config` still, but...) Input to real-world programs arrives via command lines (possibly files specified on command lines or provided as stdin), GUIs, sensors, input over some sort of network protocol, etc. The easiest first case to teach is the command line, and your students are going to have to learn a little bit about it anyway to invoke the compiler if they don't already know it. By starting to teach input from the command line, you *show students how programs they're already familiar with are doing something they do*, rather than giving them an example that seems forced/unnatural/foreign.

Others have commented that using the command line requires getting into arrays early, but you can paper over that until students are ready. I find processing input from stdin to be a good place to start too, *with the caveat that you use input redirection*. Behaviors like terminal line buffering/canonical mode are not at all intuitive to students, and detract from teaching the language. If you instead have them process input redirected from text (or binary) files, you can avoid that. Just don't use `scanf`. It's awkward, unintuitive, and often unsafe. Start with `getc`/`putc`, then `fgets` when you're ready to do some parsing.

> **Comments:**
> **username_7**: Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/96423/discussion-on-answer-by-r-why-teach-c-using-scanf-without-talking-about-comman).  
> **username_12**: Now that this question has pointed it out, the same thing is obviously true in assembly language.  So many Q&As about reading string inputs into buffers and so much code clutter from printing prompts first.  (Although we'd still get lots of asm questions about converting strings to integers, especially multi-digit strings.)  
> **username_11**: @PeterCordes: Absolutely. And it's even worse if you don't have subroutines yet, and rather misleading if you use bios/syscalls in place of subroutines. I'd hesitate to each asm as a standalone language at all, preferring to teach it first with "call from C" being the way it's invoked.  
> **username_12**: The MARS  MIPS simulator keeps things somewhat clean by providing "syscall" implementations of read integer from user-input, and of print decimal, print hex, etc.  It's very much a toy system. I think it makes command-line args accessible to modify between runs somehow, though.    For x86 Linux running natively, not in a toy simulator, probably teaching calling conventions as part of the boilerplate for running asm by calling from C would work. But it does introduce more moving parts. I can certainly see why courses don't do that, at least if they try to do asm before student's really grasp C.  

---

### Answer by username_13 on 2019-07-18. Score: 14

Because, traditionally, programs iterate over data. See [JSP](https://en.wikipedia.org/wiki/Jackson_structured_programming).

Admittedly, prompting the user for data is weird, however we're talking about beginners here, having them try to remember what the different fields of data they have to enter isn't the point of the exercise, and is likely to make them view interacting with computers as needlessly complicated. As a bonus, prompting for the values helps make the beginner programs self documenting - the text of the prompt is an explanation of the variable that is to be read - so this will hopefully help our novice programmers understand the simple program without introducing the complex topic of comments.

(I was taught it wasn't legitimate in early versions of pascal to output before input, so you couldn't prompt for input.)

> **Comments:**
> **username_14**: Do you have a citation for your Pascal factoid? I don't remember that one.  
> **username_13**: good question @username_14. It was something I was taught in '86, as having been the case but no longer was, but I took that as truth without asking for proof.  
> **username_9**: Wasn't it something with some implementations, like: the first reads on input return the command line, unless a write is issued on output ?  
> **username_9**: Source of a Standard Pascal compiler here : https://sourceforge.net/projects/pascalp5/  

---

### Answer by username_15 on 2019-07-19. Score: 12

From my own experience tutoring young CS students, user input is actually a tricky concept.  If it were not for user input, the results of any program could be pre-compiled into nothing but its output.
You get one lesson from getting all the input right at the beginning, with argc/argv, but from that point on, its just the computer churning.  You get a different lesson from getting input during the execution of the program.
I have found that the idea of getting input from the user is surprisingly non-intuitive, given that nearly every program we interact with on a daily basis does it.  This suggests that introducing it early helps prune misconceptions about how computers work before they become a real problem.
Obviously not every student is the same, but a particular pattern I found occurs more than I'd like is that they can understand what a program should do when it executes but not how that actually happens.  They can look at
BOOL x = TRUE;
if (x)
    printf("Hello\n");
else
    printf("World\n");

And they can intuit that the program should print "Hello", but they can't intuit how a computer can possibly do so.  As best as I can tell they figure the compiler does the "magic," and figures out which printf to use (we'll ignore optimizers for a moment).
However, when the values come from input, you can no longer think about the computer as a magic device which reaches the final result immediately.  You have to see that it is following steps.  We know this, but it seems many students don't grasp this at first.
If you have inputs coming from argv, its easier to keep this illusion going.  If you have input during the program, after the program has already done something, you have to realize what's going on quicker.  In particular, it gets you closer to the point of realizing that the input the computer asks for may vary based on previous inputs (press 1 to calculate the area of a circle, press 2 to calculate the area of a rectangle.  Depending on the next scanf/gets, the computer will ask for one additional number or two)

> **Comments:**
> **username_6**: Could you elaborate on the unintuitive bit?  I'm always on the lookout for new cognitive traps that I haven't noticed before.  
> **username_15**: @BenI. I've found that some students learn the concept of functions before they grasp the idea of execution.  They can wade their way through the code and make sense of it in their head, but they can't see that the computer wades through it also, in real time.  I find the same people tend to assume that if they compile `if(x) f(); else g();`, that the compiler figures out which of those two branches will be taken, and only captures the instructions for that branch.  They get bothered if I construct examples where it's hard to know which branch will be taken (such as when there is input)  
> **username_6**: Fascinating!  Could you add that into your answer?  It would make the answer more valuable.  
> **username_16**: As a teacher: mind blown. If your anecdote is correct, there must be some subset of students who don't grasp the concept that the code for both branches are in the executable, but one of them gets skipped over at runtime. Very interesting!  

---

### Answer by username_14 on 2019-07-18. Score: 6

Ultimately they need to understand both ways. Which you do first seems to be a matter of preference - or maybe just following the textbook.

They need to understand at some point that 'main' in C is an interface with the OS. But, since you can't teach everything at once, you have do pick the order of instruction. But teaching command line params later can give you a way to talk about "elegance" in program design.

Of course, the program written to accept args needs to behave properly if none (or too few) are presented. Often this defaults to prompting for data in simple programs.

> **Comments:**
> **username_12**: You make an interesting point about validating input.  But I don't think falling back to prompting makes any sense for a simple toy program.  `if(argc < 4){ puts(USAGE); return 1;}` near the top of main.  Maybe with a specific message like "too few args" as well as the usage string.  
> **username_12**: When it comes to parsing each arg in turn, handling errors is maybe more problematic (like a string where there should be an integer).  Prompting 1 at a time with scanf gives a different debugging experience.  One bad input can block the rest of the inputs if you don't do error checking and remove the bad token from stdin.  But a failed `atoi()` or `strtoul` just produces zero.  There's something interesting to be said there about the difference in how you validate input and report errors, and the debugging experience for total beginners.  
> **username_12**: `atoi` is probably easier: a debugger can find that it's returning zero, and/or that you're calling it on the wrong string.  But a debugger generally can't observe the stdin I/O buffer to find out why some combo of input + format string is making all the later `scanf` calls fail.  (Same applies to debug-printf statements for people that haven't yet learned to use a debugger.)  

---

### Answer by username_4 on 2021-02-23. Score: 3

This answer comes from experience teaching C to students that have about 2 years of programming experience in Python and no exposure to low-level programming. I teach an Operating Systems-like course and students take introductory C lessons before the main course.

---

For C begginers strings are hard. Although the concept seems rather easy, students struggle with the differences between '0' and the number 0 and with the whole "we represent characters as numbers" thing. So, for many students coding `atoi` is a challenge at first. Expressions such as such as `str[i] - '0'` are not obvious at all and things like comparing characters make no sense (`str[i] >= '0' && str[i] <= '9'`). Even 'a' and 'A' being different sometimes confuse students.

A second point is that `argv` is a pointer to `char` arrays, resulting in the type `char *argv[]`. This is not ok until students are comfortable with pointers and even then a pointer to an array takes some thinking for many students. Drawing the pointers helps a lot here.

Taking these two points into account, we use `scanf/printf` because it allows us to have students accepting user input and showing program results right from day one. We also teach `fgets` and input/output redirection as early as possible (so at least students understand that interacting with programs in the terminal is not the norm). The main point is that *C* has strange syntax and inner workings for students that have only used Python, so taking it slow helps. Also, they do not know the use of `argc/argv` yet, so we would have to teach it as well.

Later in the semester, when they are more prepared, we present `argc/argv` as a way of receiving arguments *from another program*. Students by then are able to quickly understand how to use it and can write well-behaved programs.

So, yeah.... teaching `scanf/printf` without ever talking about proper command line programs is not a very good approach. I would even say more: teaching *C* without a connection to how *C* is actually used is not a very good approach. The connection might be weak at first, but it must be made strong at some point. Otherwise, why would we be teaching such strange language if the programs students code are much more easily done with other languages?


---

### Answer by username_5 on 2021-02-24. Score: 0

Don't teach scanf. It is dangerous and it is a huge security leak. Use getline instead and limit input size. Then you can use functions in stdlib.h to parse your string into the desired type.


---

