korki’s corner

(or teaching undergrads how to code in C)

Last semester I was asked to support a class of undergrads for an introductory course in programming languages (namely plain old ansi C). During the semester various problems made the students underestimate C and its capabilities (maybe even hating the lang), making the course not just boring but also incomprehensible;

One fact worth mentioning is the “educational approach” taken by one of the tutors [1]; He created a small intresting game app (battleship), that arouse the students curiosity and intrest to create the application (in fact some were intrested in using ncurses for the term handling), and during the app build up he introduced some important aspects of the C programming (i.e. datatypes, var scope, functions , pointers , arrays, dynamic mem allocs, etc…). At many levels students of this class had many chances to stimulate their creativity using C, and some did so.

During this quest of getting familiar with a sturdy programming language like C many people had “enough” issues (issues that somehow are not usually addressed and are carried along the programming lifecycle for ages, even after graduation ). Some of the important ones are:

• You shouldn’t create dynamic arrays. Period
  • Whille the following code is valid on some compilers (namely gcc) the programming concept is inconsistent with the primitive language ideas


...
int a;
scanf("%d",&a);
int arr[a];
...


• The implicit declaration of function xyz is not just a trivial warning that can cause no harm. This warning identifies a flaw in the programming habbits. When you use a function YOU must include the corresponding header where the prototype of this function lives!
  • For instance if you are using the <code>system</code> function, you ought to include the <code>stdlib.h</code> header. Of course usually there are no different implementation of the system function in the same arch but what about with the <code>malloc</code> directive? [hint: <removed the hint> ]. You may run into real trouble if you let the compiler decide the malloc behaviour.
• Casting! What can one say about casting… (incorrect) Casting is usally a reason for runtime errors (i.e. segfaults), so students should be extra carefull when casting
• Free the damned memory (I guess this is minor since when a programmer builds a memory intensive program he will take into account the needed memory but hey one should keep in mind that this may be a problem at one point)
• using the wrong tools building their apps
  • Well let me tell you… Using the stupid DevShed is the single worst IDE for C/C++ i’ve ever seen. If you are about to learn programming, you should use a tool that may be reusable at some point later (like all software components should do); So why not using some wonderful opensource multiplatform dev IDE like a) eclipse [2] b) netbeans [3] c)or even sun studio [4]. Why bother with something so immature like devshed?
  • CC. A developer should be able to use some command tools at some point. things like {c,g,’ ‘}make, ld, ar, gcc ,icc mayor may not need some finetuning at some point. so why not messing around with them a bit.
  • DEBUGGING: Mandatory! -g, -Wextra, -Wall maybe type checking for even stricter code (-pedantic and/or -ansi and/or -c99 and/or …)
    • Some use of gdb (do just a backtrace mate)
    • strace (if the students get a glimpse of system calls during the classes )
    • some other cool debugger that I haven’t heard of (please comment about it if it’s F/OSS)

This is the short version of the issues (certaintly I forgot lots of other minor cases) but in my opinion these are major issues a class should emphasize on (if you have any other on mind please elaborate)!