Re: (anal) Q: Are there any coding styles or development guidelines?

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 22, 2005, 17:50 UTC
Message-ID: <Pine.LNX.4.58.0504221044400.2344@ppc970.osdl.org>
In-Reply-To: <20050422155845.GC52771@xdt04.mpe-garching.mpg.de>

On Fri, 22 Apr 2005, Klaus Robert Suetterlin wrote:

Show 9 quoted lines

>
> I'm currently doing a source audit of the git core components.
> Mainly I want to check if I can spot some left over memory leaks.
> 
> Unfortunately ;) I didn't find any so far (after reading five files).
> 
> Still I did find quite a lot of stuff that lint would most likely
> complain about.  Like not checking return values.  Should this be
> fixed now or isn't it time to do the cleanup, yet?

I personally don't think we're quite there yet. You'll note that a lot of routines just call "die()" when they don't find the data they want etc. All things that we probably will need to clean up eventually, but is fine for now.

> I also found several literal copies of the same function including
> function name, parameter list, etc.  Wouldn't it be better do clean
> those up and put them in a utility.{c,h} file?

Yes, we can start doing things like that, especially if they really _do_ end up making sense in a bigger picture.

Some of that is because I didn't clean up the Makefile until fairly recently, so it used to be harder than it is now to have a shared object file. In contrast, now you just add it to the list of library objects, and off you go.

> A similar problem
> is the continous reimplementation of linked lists, dynamic memory,
> smart strings / vectors, etc.

Sometimes specific duplication is just _easier_ than trying to be clever and having some generic shared version. For example, there's a few data-specific versions of "insert into sorted array" there, and the fact is, they are so simple that it's likely less work to keep them that way than it would be to create some "generic" thing that did it and was passed in some descriptor of the data.

Generic routines aren't always good. Sometimes the abstraction ends up adding more of a mental burden than just doing the thing in a simple way in the first place.

> And then there are some stale files (i.e. revision.*) that the Changelog
> already mentions as removed, but which are still active in HEAD.

They definitely are _not_ active in HEAD, at least not in my version.

You may have stale copies in your directory, but they should show up as being stale when you do "show-files --others".

		Linus