Re: [dwm] Coding styles

I'll try to add some more precisse descriptions on the points :)

Before anything else...Thanks for the feedback.

On Thu, 2008-07-31 at 14:14 +0100, Anselm R Garbe wrote:
> 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.

yes, IDEs usually forces you to continue using their IDE, making
impossible to work from outside editors or compile with other tools. And
thats somewhat anoying imho. I have noted this in the wiki.

> 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.

i think there some gnome-based which are quite based on autotools and
gnu make, but the only reason for using an IDE is IMHO the code
autocompletion (which is not required on well designed software) and
code browsing (which can be replaced by command line tools like ctags)

> 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
(..)
> 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.

use emacs. it have a very good integration with gdb.

BTW i dont like to do that.

> 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.

you're lucky if using it on linux. The problem is not only GDB. The
kernel interface for debugging on most of the free operating systems
lacks lot of extensibility and threading problems.

Apple has done a good job on the Mach interface for it. And
windows...well they have implemented lot of things xD

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

gdb is to blame. That's why im implementing radare, but radare it's not
a source-level debugger. But i plan to add better dwarf support beyond
1.0

> 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.

try it out http://radare.nopcode.org/ :)

Every time i use gdb i have to re-learn some commands, and this only
happends to me with gdb. Vim, radare, shell, python, ... are more
logical to learn. IMHO

> > 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.

i use #define u64 unsigned long long for readibility, but sure. its a
define and should be U64...but this is just a workaround to fix the
typedef impossibility to redefine types or check if they are already
defined.

> > 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.

Yep, its rare and should be avoided if possible.

> > 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 ;)

i prefer to use basic types than putting everything in uppercase
everywhere. The source code doesnt looks clean to my eyes. because im
using this as a type and not as a macro or a constant definition.

> > 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.

ehehe, i think most of the rules of my wiki cannot be applied to
commercial software O:)

> > 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.

Uhm. i dont like to mix spaces and tabs for indenting. Is better to let
this job to the editor. And keep everything in tabs (smaller source
files and easier editor integration)

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

yes, only if possible. not for binary flags or stuff like:

enum {
  FOO_BAR = 0x8048400,
  BAR_FOO = 0x1000130,
  ...

which is obviously a bad use of enums.

> > 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

Nice hack ;)

I agree with you. C is statically typed language. LISP isn't and its
evaluated in runtime, C is compiled and executed. Trying to implement
some dynamic features on C breaks the basic concepts of the language.

>
> > Uppercase everywhere
>
> Well, macros should be uppercase ;)
>
> #define UINT unsigned int

hehe, i dont like them , but i agree that they are defines ;)

> > 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.

me too

> > 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 ;)

hehe, thats right, but maybe what you need is a tracer and not a
debugger, and there are not much good tracers. I wuold like to write for
radare a script in perl or so to be able to trace between from/to
different source:lines.. something like printf debugging but in a
cleaner way :P

> > 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.

well. thats true, but most of the software is designed to run on
posix-like systems. At least posix is an easy standard. Using posix I
have made applications making it run on GNU/BSD/w32/wCE/OSX whcih is a
big percentatge of the OS market.

Symbian is a cancer.

> > 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.

Yes, thats what i would like to see.

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

if you dont use special chars, using utf8 is the same as ascii7.

> > 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.

perl ppl uses comments in the source code to parse them in perl and make
some precompilation checks for generating include files, documentation,
hirearchy and so. which is nice imho, because with a C parser you cannot
express all the pre-post conditions of a function.

And having tools like these is good for software quality.

> 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.

Yeah, but this should only happen on privative software.

> > Include files are for signatures
>
> I know one exception here, extensions to dwm's config.h -- but I won't
> change it ;)

and I agree with you in this case ;)

> > 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.

Sometimes is hard to do this on big projects. but sure it needs
refactoring. But there's lot of people writing really weird hacks
because they dont know this trick.

> > Uppercase/Lowercase functions
>
> Agreed, though I even tend to minimize the underlines if possible.

for "huge" apis is better to be more verbose-friendly. The GTK coding
standards are really good from the hirearchy pov. and Vala is the best
example of how to take profit of it :)

> > 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.

Yes, only for kernel stuff and some error checking conditions.

> > Don't read this document
>
> Agreed, except that I like the UINT/BOOL/ etc stuff from MS.

arg!

:)

--pancake
Received on Thu Jul 31 2008 - 14:41:12 UTC