[wiki] [upstream] added style guid I started sometime ago || arg

From: <hg_AT_suckless.org>
Date: Wed, 23 Jul 2008 11:28:49 +0100 (BST)

changeset: 70:ae8b50d06d6d
tag: tip
user: arg_AT_suckless.org
date: Wed Jul 23 12:28:45 2008 +0200
files: common/style_guide.md
description:
added style guid I started sometime ago


diff -r db5eeab111c8 -r ae8b50d06d6d common/style_guide.md
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/common/style_guide.md Wed Jul 23 12:28:45 2008 +0200
_AT_@ -0,0 +1,52 @@
+Style guide of code hosted on suckless.org
+==========================================
+When it comes to code style questions, it is very likely that individual
+programmers will disagree with certain guidelines. It is absolutely fine to use
+an individual style for individual projects, especially if only one developer
+is involved. However, if there are two or more programmers involved in a
+project, a guidelines gets handy to meet the first basic rule we follow:
+
+* Code developed by different individuals should follow a common style among those to found a consistent base.
+
+Thus consistency in the code style being used is more important than any
+particular detail of the style itself. Due the fact, that most software of
+suckless.org has been developed by more than one individual, some sort of
+common style found in the code appeared during the past years. This common style is
+described in detail, further on.
+
+C++
+---
+C++ was used in the early beginning and has been abandoned for various reasons.
+
+A summary of those reasons is: Nearly nobody understands C++ in all its
+facettes and details. C++ has been designed and evolved to support any
+programming language paradigm and feature that has been invented by programming
+language designers until the OO hype and beyond. This leads to mutual
+exclusive programming paradigms and styles in one language and basically
+destroys the simplicity, beauty and clarity of its ancestor C. The usual
+workaround in the C++ world is to stick to certain C++ subsets, like only using
+one calling convention, not using exceptions, not using STL but using libstdc++
+etc.
+
+It took quite a while for some of us to realize that C++ leads to more complex
+software in general, because it provides the feature richness to do so. This is
+especially dangerous if average programmers are involved in a project. In our
+experience it is much more likely that a C++ project driven by average
+programmers will fail, than a C project driven by average programmers. The
+reason for this is simple: C++ is hard to deal with when it is used in all its
+feature richness.
+
+We don't argue that C++ software performs better or worse than software written
+in C, because this is silly. However we argue that in general C++ software
+performs much more poorly than software written in C, because of its tendency
+to complexity and its hidden pitfalls like expensive function calls in loops or
+too many inlines.
+
+All these problems do not happen with C, because C is to simple for being
+misused in too many ways.
+
+So we come to the second rule of this style guide:
+
+* We use C as primary programming language because it is clear, simple, and beautiful on its own already.
+
+TODO
Received on Wed Jul 23 2008 - 12:28:49 CEST