Programming in C (BCA 102): How to Actually Learn It

Programming in C is BCA 102, a three-credit course in the first semester with three lecture hours and three practical hours a week. It is also the course that decides how comfortable you will be with everything that follows, because the mental habits you build here transfer directly to data structures, operating systems and networking.

The mistake most students make is studying C as a set of syntax rules to be recalled in an examination. C is small, and its syntax can be learned in a few weeks. What takes longer is understanding what the computer actually does with your code, and that understanding is what makes the difference between writing a program that happens to work and writing one you can reason about.

Understand the compilation model first

Before pointers, spend an hour on what happens between your source file and a running program. Four stages occur in order: preprocessing, compilation to assembly, assembly into machine code, and linking of object files and libraries into an executable. When the compiler reports an error, knowing which stage failed tells you where to look.

Practise this at the command line rather than only inside an editor button. Save a file as hello.c, then run gcc hello.c -o hello and ./hello. Try gcc -E hello.c to see preprocessed output, and gcc -S hello.c to see the generated assembly. You do not need to read the assembly; you need to know that it exists and that the toolchain produced it in stages.

• A compiler error stops the build; a linker error means the build succeeded but a symbol is missing.
• A warning is not a compliment. Compile with -Wall and fix warnings while the program is small.
• One source file usually means one translation unit, which is why a function must be declared before it is called.

Pointers are just addresses

A pointer is a variable that holds a memory address. The two operators you need are & to take an address and * to follow one. If int n = 5; then int *p = &n; makes p hold the address of n, and *p reads or writes the value stored there. Write that pair on paper until it stops feeling strange.

The reason pointers matter is that C passes arguments by value. To let a function change a variable in the caller, you pass its address. That is how scanf writes into a variable you own: scanf("%d", &n) hands the function the address rather than the value. Once that clicks, pointer parameters stop looking arbitrary.

Arrays, strings and structs

An array name behaves like a pointer to its first element, which is why arr[i] and *(arr + i) mean the same thing. This also explains why arrays are not copied when passed to a function, and why the function has no way to know their length unless you pass it separately. Indexing beyond the end of an array is undefined behaviour: it may crash, or it may appear to work until it does not.

A C string is a char array terminated by the null character. The terminator is easy to forget, and forgetting it is the cause of a large share of beginner bugs. Functions such as strlen, strcpy and strcmp do not allocate memory; they operate on buffers you must size yourself. Prefer length-bounded versions like strncpy and always check that the destination has room.

A struct groups related values under one name and lets you pass a coherent record around. Access members with a dot for a struct value and an arrow for a pointer to a struct. Passing a pointer to a struct is the usual choice when the function needs to modify it or when the struct is large.

File input and output

File handling follows a fixed pattern: open the file and get a FILE pointer, check that the pointer is not NULL, read or write, then close it. Opening can fail for reasons that have nothing to do with your logic, such as a wrong path or missing permissions, so the check is not optional. Use "r" to read an existing file, "w" to create or truncate, and "a" to append.

Mistakes beginners repeat

• Using an uninitialised variable and getting a value that looks plausible but is arbitrary.
• Reading input with scanf without checking the return value, so bad input silently poisons the next read.
• Writing = in a condition where == was intended; the compiler warns, but only if warnings are enabled.
• Returning a pointer to a local variable, which becomes invalid the moment the function returns.
• Forgetting to free memory allocated with malloc, or freeing it twice.
• Using a string function on a buffer that has no room for the terminator.

A practice routine that works

1. Spend twenty minutes reading, then type every example from the lecture by hand instead of copying the file.
2. Predict the output before you run the program; when you are wrong, work out why.
3. Rewrite each lab exercise from a blank file a day later, without notes, and see what you forgot.
4. Break your program with deliberate errors, such as an off-by-one loop bound, and observe the failure.
5. Keep a single file of working snippets you can reuse, grouped by topic rather than by date.
6. Compile with warnings on every time and treat each one as something to fix, not suppress.

If you are starting the first semester, it helps to see the whole term alongside this course. The first semester guide covers all six courses, the lab rhythm and what to set up in the opening weeks.