---[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 01 of 20
-------------------------[ P H R A C K 5 2 I N D E X
--------[ Choose your own $PATH adventure
Whew. You would be quite surprised at the evil wheels I had to set in
motion in order to get this issue out. According to Newton, a Phrack Issue
remains at rest or continues to move in a straight line with a uniform
velocity if there is no unbalanced force acting on it. This issue was at rest.
Its velocity was constant. And there were few forces acting on it. Anyhow,
after many machinations it's here. Enjoy.
I have a gripe. Something upon which I'd like dwell for a spell. Let's
talk about coding aesthetic (from the C programming standpoint). Now, this is
not a harangue about effective coding or efficient coding, I'll save those for
some other time (perhaps for the time when I feel I can write effective and
efficient code proficiently enough to vituperate to those who do not). I
want to touch down on a few topics of visual appeal, which are overlooked so
often.
The five major areas I will cover are indentation, brace placement,
use of whitespace, commenting, as well as variable and function nomenclature.
I suppose I should also mention that coding style is a personal preference
type of thing. There are all kinds of schools of thought out there, and all
kinds of methodologies on how to write pretty code. In the grand scheme of
things, none are really any more correct than any others, except mine.
C is, for the most part, a format free programming language. Code can be
written with all manner of whitespace, tabs, and newlines. The compiler
certainly doesn't care. The machine doesn't care. This can be a double
edged sword. There is quite a bit of room for artistic interpretation. And
just like in real life, there is a lot of crappy art out there.
Indenting your code is a must. Please, do this. Indentation is here for
one simple reason: to clearly and unequivocally define blocks of control.
However, 8 space tabstops are overkill. Unless you are using a 2 point font on
a 13" screen, 4 spaces should easily define your control blocks. This allows
you to maintain clarity on an 80 column screen while nesting blocks of control
much deeper then you would with 8 space tab stops. 2 space tabstop advocates
should be shot. However, don't let typography take over your code (ala ink
obscuring the intent). If you have 7 million levels of indentation, perhaps
you should rethink your approach to tackling the problem...
Bracing has a simple solution. The most effective use of bracing is in
placing them on newlines so that they neatly enclose the area of control. This
is especially important with nested levels of control. I know this generates
empty lines. Oh well. They're free. Blocks of control become easily visible
and it is easy to isolate one from another. This goes for functions as well
as conditionals and loop structures. I know I go against K&R; here. Oh well.
In the pursuit of clear, readable code, whitespace is your friend. Single
space all keywords and all variables and constants separated by commas. It's
a simple thing to do to drastically improve readability. When you have a
series of assignments, one after another, it's a nice touch to line them up on
the closest relative 4 space boundary. And please, no spaces between structure
pointer operators and structure contents.
Commenting is a delicate matter. Descriptive, concise, well written code
shouldn't really need commenting, or at least very much of it. But this isn't
a rant about descriptive, concise, well written code. If you feel the need
to comment your code, follow a few simple rules:
- Keep the comment block as small as possible.
- Don't tab out your comment frames to line up with each other. That's
just plain fucking annoying. If you're doing that, you have too many
comments anyway.
- Commenting datatype declarations rather then the functions that
manipulate them is usually more helpful.
- If you must comment, keep your style as consistent as possible. If the
commenting detracts from the readibilty of your code, you've just ponied
up any clarification you might have achieved with the commenting.
The major exception to these rules are file headers. The beginning of
source and header files should always have some descriptive information,
including: file name, author, purpose, modification dates, etc... These
comment blocks should always have a simple vertical line of unobtrusive
astricks, framed with the required forward slashes. People using C++ style
commenting in C programs should be drawn and quartered.
The other exception to this rule is when you are writing code specifically
for the benefit of others. If the code is intended to be a learning tool,
copious commenting is allowable.
Variable and function nomenclature should have connotation as to what their
purpose in life is. As short as possible while still preserving some sort of
identity. Descriptive names are wonderful, but don't go overboard. Generally,
a condensed one or two word descriptor (possiblely connected via an underscore)
will work fine. And please, no mixed case. The only time uppercase characters
should appear in C code are in symbolic constants and macros (and possibly
strings and comments).
This tirade is the result of my experiences in reading and writing C code.
In my travels as a stalwart mediocre programmer, I have progressed through many
levels of maturity in my programming style. Much of my old code exhibits many
of the very things eschewed as anathema in this jeremiad. Well, what can I
say? I believe that I have grown. I am at home with the me. This is me
breathing. (Tell me what movie that's from, and I will give you a Phrack
Donut.)
Enjoy the magazine. It is by and for the hacking community. Period.
-- Editor in Chief ----------------[ route
-- Director of Public Operations --[ dangergirl
-- Phrack World News --------------[ disorder
-- Werdsmith ----------------------[ loadammo
-------- Elite --------------------> asriel
-- Santa vs. Jesus ----------------[ ISS vs. SNI
-- Festively Plump ----------------[ Cartman
-- Extra Special Thanks -----------[ No one.
-- Official Phrack CD -------------[ FLA/Flavour of the Weak
-- Official Phrack Drink ----------[ `The C Kilborn` (2.9 parts ketel one,
-----------------------------------| .1 parts tonic)
-- Shout Outs and Thank Yous ------[ Lords of Acid, cantor, Yggdrasil,
-----------------------------------| snokerash, Voyager, TNO, Jeff Thompson,
-----------------------------------| angstrom, redragon, Rob Pike, halflife
-- B.A. Baracus Phrack Fracas -----[ loadammo vs. Death Veggie
-- Original flip.c author (props) -[ datagram
-- Gas Face Given (drops) ---------[ solo, klepto
Phrack Magazine V. 8, #52, January 26, 1998. ISSN 1068-1035
Contents Copyright (c) 1998 Phrack Magazine. All Rights Reserved. Nothing
may be reproduced in whole or in part without written permission from the
editor in chief. Phrack Magazine is made available quarterly to the public,
free of charge. Go nuts people.
Subscription requests, articles, comments, whatever should be directed to:
[email protected]
Submissions to the above email address may be encrypted with the following key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW
ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O
vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j
0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W
DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG
/v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu
Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=
=1iyt
-----END PGP PUBLIC KEY BLOCK-----
As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED. Phrack goes out
plaintext. You certainly can subscribe in plaintext.
phrack:~# head -20 /usr/include/std-disclaimer.h
/*
* All information in Phrack Magazine is, to the best of the ability of the
* editors and contributors, truthful and accurate. When possible, all facts
* are checked, all code is compiled. However, we are not omniscient (hell,
* we don't even get paid). It is entirely possible something contained
* within this publication is incorrect in some way. If this is the case,
* please drop us some email so that we can correct it in a future issue.
*
*
* Also, keep in mind that Phrack Magazine accepts no responsibility for the
* entirely stupid (or illegal) things people may do with the information
* contained here-in. Phrack is a compendium of knowledge, wisdom, wit, and
* sass. We neither advocate, condone nor participate in any sort of illicit
* behavior. But we will sit back and watch.
*
*
* Lastly, it bears mentioning that the opinions that may be expressed in the
* article of Phrack Magazine are intellectual property of their authors.
* These opinions do not necessarily represent those of the Phrack Staff.
*/
-------------------------[ T A B L E O F C O N T E N T S
1 Introduction Phrack Staff 12K
2 Phrack Loopback Phrack Staff 60K
3 Line Noise various 79K
4 Phrack Prophile on o0 Phrack Staff 07K
5 Everything a hacker needs to know about getting busted Agent Steal 72K
6 Hardening the Linux Kernel daemon9 42K
7 The Linux pingd daemon9 17K
8 Steganography Thumbprinting anonymous 35K
9 On the Morality of Phreaking Phrack Staff 19K
10 A Quick NT Interrogation Probe twitch 18K
11 Subscriber Loop Carrier voyager 48K
12 Voice Response Systems voyager 18K
13 Pay Per View (you don't have to) cavalier 19K
14 The International Crime Syndicate Association D. Demming 20K
15 Digital Certificates Yggdrasil 14K
16 Piercing Firewalls bishnu 31K
17 Protected mode programming and O/S development mythrandir 76K
18 Weakening the Linux Kernel plaguez 27K
19 Phrack World News Disorder 64K
20 extract.c Phrack Staff 08K
687K
-----------------------------------------------------------------------------
When Sen. Bob Kerrey (D-Neb.) was asked to define encryption, the results
were horrific. "Well, I mean, to answer your question, I mean, encryption is
-- the political equivalent of encryption is you ask me a question, I give you
an answer and you don't understand it," he managed. "I mean, I intentionally
garble the answer frequently. I intentionally garble the response so that you
can't understand what I'm saying. And that's -- you notice that I've got the
ability to do that."
-----------------------------------------------------------------------------
----[ EOF