Re: [dwm] Coding styles

Ok, here we go:

> Don't use IDEs

I agree to some extend, though it's not because I think that IDEs are a bad
idea, it's more because most IDEs aren't usable or do too much. At work I use
Visual Studio quite frequently, basically for debugging weird problems in
commercial code. However I'm using vim for editing the source code
most of the time.
My main concerns about Visual Studio are that it invented its own layers of
storing meta data and controlling the build process, and that its
rather WIMPish.

A decent IDE should just stick to running make and parsing it's output. vim
does this for me, but writing Makefiles on Win32 is a pain in the ass. The meta
data issue is that VS depends on those vcproj files, which include all
information about the associated files of a project. That's too much already, a
decent integrated filesystem browser would be enough in my impression. Plan 9's
acme has got a lot things right in this regard, but it looks horrible imho and
is too mouse-driven.

Of all IDEs I had to use so far, I'd consider VS the best of all still. Eclipse
for instance is not a good alternative, since it does a lot more than VS, and
performs really poor for what it does. For Java-only projects the Eclipse
debugger is ok, though I'd still stick to vim or the vi Plugin most of the time
at least. -- What I like in Eclipse and VS is the reflection support during
editing. It is quite handy to see which fields/functions a certain struct/class
supports without opening a separate file. I also use the "Got to
definition/declaration" context menu entries quite frequently, it safes a lot
of time, though I'd prefer an Acme-style way for doing so.

So what I really miss in the OSS world is a decent debugger and a decent
debugger IDE which might work together with my editor of choice fairly well.
A decent debugger IDE should allow stepping through the code synchroneously
fairly well.

The problem with gdb is, that it's absolutely crap compared to the MS debugger -
especially if you have to debug an app which makes use of multi-threading. gdb
gets quite confused and takes ages to follow the control flow.

I tried KDevelop, which comes with the "somehow" best visual debugging
experience, but it suffers from the poor gdb implementation.

Unfortunately my knowledge is too limited to write my own debugger. Using gdb
on the command line is a pain in the ass in my opinion. It's hard to step
through the code easily.

> Fit your code in 80 columns

Well, I try to, though I like doing occasional exceptions with this, especially
if your code looks more clumsy with forcing it into multilines. Sometimes there
is not much of a choice, if the API you are using is not under your control. I
also think that terminals nowadays should consist of more than 80 cols, say 100
or 120 cols. At least st will do so quite well.

> Basic types

Well, here -- totally against all Unix styles -- I prefer the MS way of
defining shortcuts for basic types. I kind of dislike recommending:

#define uint unsigned int

simply because I think, that all macros should be uppercase. MS does
it this way:

#define UINT unsigned int

and that looks better to me. The problem with doing

typedef unsigned int uint;

is, that uint might be typedef'd already on some system, but maybe not on the
developers system, that's why I agree with you using define OR stdint.h, but
not defining eventual C99 typedefs using define.

> Don't abuse stack frames

I agree here, though I kind of accept exceptions here. Sometimes it just
"feels" better to nest something into an inner scope. But this is really rare.

> Use pointer tables

I mostly agree. Though I would limit this only to eliminate big switch-es, it
is fine to avoid additional function calls if it's a small switch with say < 7
cases and doing it directly in the case branches.

> Don't abuse type definitions

Well as stated at the basic types, personally I kind of would go the MS route
in this regard, knowing that this is politically incorrect in the Unix world.
That's why I tend not just stick to 'unsigned int' instead of uint or UINT ;)

> Using SingleLine comments to comment >1 lines of code++

Depends, I usually only comment background/context information, since the code
is speaking for itself. I also tend to comment header files a lot (at work ;(
-- to document pre- and postconditions etc, expected input values, and possible
results. Of course only if it's an API function which is included from
somewhere else.

> Mixed tab/spaces++

I use tabs for indentations and spaces to align things beginning at the
indentation level, eg in multiline constructs or sometimes in variable
declarations if it looks easier on the eyes. Though the latter case can't be
found in open source stuff I wrote.

> Enumerating with defines

This is not very clear to me, you recommend enum {} when possible, right? If
so, I totally agree.

> Local functions

Nested functions in C feel wrong to me. This is C, this is conservative and
simple programming style. This is not functional programming. Don't do it.
There is no reason to have nested function, use static local functions instead.

Btw. static functions are real information hiding, in contrast to the
private/protected hack in C++ which only performs compile time checks, but
during runtime you can treat private class members like struct fields using the
following trick:

#define private public
#define protected public

;)

> Uppercase everywhere

Well, macros should be uppercase ;)

#define UINT unsigned int

> c99 stack frames

I agree mostly. I'd just recommend to use classic C-style variable
declarations, always at the beginning of a function/source file or header file.

> Debuggers are not for coding

Agreed, though, at least those of us financing their life doing development
know that once you enter the commercial software world, you don't live in your
own controllable universe anymore. And you are forced to deal with software you
haven't written and to find bugs you haven't caused. A debugger helps a lot
here, and I really miss a decent debugger on Linux. Actually the lack of a
decent debugger on *NIX is one reason imho that still a lot of development is
done on Win*, even if the product is portable (or especially if it is).

Note, I agree that good software needs no debugger, because it is simple. But
the real world doesn't consist of good software, and I have to live from
something ;)

> System specific calls

Well not every platform supports POSIX, I'd really like to see a decent and
simple portable OS abstraction library, which supports nearly all platforms,
from Unix, Windows, WinCE to Symbian ;) That would make my current business
life a lot easier.

> Package on top of a root directory

This is not absolutely clear to me. Do you argue that a tarball should extract
into a separate directory and not into the current directory? Then I agree.

> Don't use locales

Don't use locales at all. Use UTF-8 only, which is fine with the basic
char type.

> Comments are for humans

Well as others stated, background and context info should be commented if it
supports understanding the implementation. E.g. commenting pre- and
postconditions, or especially why the data structure has been designed that
way, is absolutely fine to me.

I heared from someone that there was some software research which concluded,
that usually all source code is read by at least 8 different people during the
time -- so commenting hidden facts is really good.

> Include files are for signatures

I know one exception here, extensions to dwm's config.h -- but I won't
change it ;)

> Dont include more than once
> Use #ifndef _INCLUDE_FOO_H_ ; #define _INCLUDE_FOO_H_ to avoid including the same file twice.

I hate this rule. Good software should not need these hacks (or
#pragma once as alternative).
It is a sign that something is seriously broken, if you include a header file
multiple times, and you should refactor it. This is no issue for dwm, but you
will notice that all wmii-related projects aren't affected by this issue.

> Uppercase/Lowercase functions

Agreed, though I even tend to minimize the underlines if possible.

> Dont use labels

Every switch-case is a label ;) I would consider labels ok as long as they are
local inside a function and rarely used, eg. for error checking. Dozens of
return's will make the machine code even worse, than a simple error goto.
But use them with care.

> Don't read this document

Agreed, except that I like the UINT/BOOL/ etc stuff from MS.

Kind regards,
Anselm
Received on Thu Jul 31 2008 - 13:14:58 UTC