[wiki] [official] some polishing, real stylguide will be pushed later || arg
changeset: 73:15a8c5f0f105
user: arg_AT_www.suckless.org
date: Tue Jul 29 09:27:37 2008 +0100
files: common/style_guide.md
description:
some polishing, real stylguide will be pushed later
diff -r 7561298a9d35 -r 15a8c5f0f105 common/style_guide.md
--- a/common/style_guide.md Tue Jul 29 00:06:50 2008 +0100
+++ b/common/style_guide.md Tue Jul 29 09:27:37 2008 +0100
_AT_@ -1,18 +1,18 @@
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:
+programmers will disagree. 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.
+common style found in the code appeared during the past years. This common
+style is described in detail, further on.
C++
---
_AT_@ -20,10 +20,10 @@
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
+programming language paradigm and feature 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
+destroys the simplicity 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.
_AT_@ -32,21 +32,18 @@
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.
+programmers will fail, than a C project. The reason for this is simple: C++ is
+hard to deal with when 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.
+in C. However we argue that in general C++ software performs poorer 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.
+misused in our opinion.
-So we come to the second rule of this style guide:
+So the second rule of this style guide concludes:
-* We use C as primary programming language because it is clear, simple, and beautiful on its own already.
+* We use C as primary programming language because it enforces clear and simple software.
-TODO
Received on Tue Jul 29 2008 - 10:33:12 CEST
This archive was generated by hypermail 2.3.0
: Thu Sep 13 2012 - 19:30:22 CEST