Why I learned C "Category-0" Style

2023-03-16T20:02:00-07:00

I've been asked a few times over the years why I chose to learn C with the colloquially-known "K&R C Bible", and specifically the Category-0 style, coined on USENET back in the day.

For those unfamiliar, I'm talking about The C Programming Language, 2nd Ed., by Brian Kernighan and Dennis Ritchie, the creators of the language. In it are a series of exercises that the reader can work on to build their knowledge of C through actually building something with it. On comp.lang.c, people would share their solutions to exercises in this book. After a while, they coined different categories of solutions, to refer to their robustness and complexity.

Category-0 is solving each exercise using only the knowledge the book gives you, up to that point. In other words, it's to approach it as a complete newbie and see what you can put together using only the stuff you've learned in the book.

I had considerable difficulty learning C at first, due mostly to its similarities to C++, the challenge of finding good advice and practice, etc. I settled on the K&R because it was written by the original language authors. By choosing my reference on that criteria, I was certain to find a book that was more accurate than most, at minimum.

After buying my copy and eventually discovering the clc-wiki, I started grinding out my own K&R solutions. As you can see via the commit log on the repository, it was a very slow advancement due to real life interfering. But I did eventually complete it, so that's cool, right?

Similarly, I have a copy of Programming in Lua, by Roberto Ierusalimschy, one of the language's authors, and it's also a wonderful resource in teaching me Lua. I've heard Stroustrup's C++ books are great for learning. I would buy a similar reference for Python by Guido van Rossum, but Python is a large beast that evolves quickly via PEPs and its online docs are superb, so I'm not sure what the value of it would be.

If you're into C, feel free to give it a look. Patches and constructive feedback are both welcome. There are plans to make a "modern C standard" version of the solutions as well, to illustrate the difference between "good code for learning" and "the way you should actually build this".

Easy diffing with Vim

2018-10-13T00:00:00-07:00

Vim has good support for showing the differences between two (or three) files with either the vimdiff command or setting up a diff session manually. This often requires opening the files in their own window panes, then using :diffthis in all the relevant files. If you're in the middle of an editing session, stopping to set up this diff session can cause you to lose focus. I wrote a function in my vimrc that automates this process, so the user can focus on making decisions instead of building their UI or some other flow-breaking process.

" Function: BufDiff
" Author: zlg <zlg+viml@zlg.space>
" Date: 2018-10-12
" License: GNU GPL, version 3 <https://gnu.org/licenses/gpl-3.0.html>
" Description: Open a new tab page with two or three buffers and enter diff mode.
" Long Description:
" BufDiff accepts two or three buffer arguments and opens a new tab page to
" work with them in diff mode. This ensures that your existing window and
" buffer layout is preserved while providing an easy way to enter a diff
" session. The arguments can be any argument that can also be passed to
" the ":buffer" Ex-command, including partial filenames (if quoted).
function! BufDiff(buf1, buf2, ...)
    let fname = substitute(expand("<sfile>"), "^function ", "", "")
    if a:0 > 1
        echohl ErrorMsg
        echomsg l:fname . ": This function accepts a maximum of three arguments."
        echohl None
        return
    endif

    " Check for a third buffer, which will default to zero if not present
    let a:buf3 = get(a:, 1, 0)

    if !bufexists(a:buf1) || !bufexists(a:buf2) || (a:0 == 1 && !bufexists(a:buf3))
        echohl ErrorMsg
        echomsg l:fname . ": One or more buffer number(s) not found!"
        echohl None
        return
    else
        tabnew
        exe ":buffer " . a:buf1
        diffthis
        vsplit
        exe ":buffer " . a:buf2
        diffthis
        if a:buf3
            vsplit
            exe ":buffer " . a:buf3
            diffthis
        endif
        return
    endif
endfunction

BufDiff() allows me to reference two or three open buffers and put them into a separate diff session via a tab page. When I'm done working with the diff session, I can :tabc to close the tabpage and my original session (from the prior tabpage) is still intact, ready for me to continue work.

Using it is simple. Let's say you invoke vim with vim foo.txt bar.txt. You'll end up in Vim with the contents of foo.txt (or an empty buffer ready for writing to said file), with bar.txt in a second buffer. If I do :call BufDiff(1,2), the new tabpage will come up and compare the two files. I could also use :call BufDiff("foo", "bar"), since the arguments get sent to the :buffer Ex-command.

The primary limitation of BufDiff is you need the files you want to compare to be present in the buffer list already. Many people begin working on their projects with a one-liner that opens all the relevant source files, so it's a limitation that I think is bearable.

If you use this function, let me know how it worked out for you! Improvements and suggestions are also welcome.

Shoutout to tockitj from Freenode's #vim channel for the inspiration.

Z Space Blog - Programming

Why I learned C "Category-0" Style

Easy diffing with Vim