public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Jens Axboe <axboe@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][CFT] IDE TCQ #3 for 2.5.8-pre3
Date: Fri, 12 Apr 2002 13:55:51 +0200	[thread overview]
Message-ID: <3CB6CB47.8090409@evision-ventures.com> (raw)
In-Reply-To: <20020412114745.GE5285@suse.de>

Jens Axboe wrote:
> Hi,
> 
> The third version is ready, lots of changes since last version.
> 
> General IDE changes (not directly related to TCQ)
> 
> - ata_request_t -> struct ata_request (was actually done before Martin
>   posted his first merge, better conform to current ide style)

Well I don't do much things for no reasons. So please allow me to
write down my reasoning. My general coding style guidiance is the following:

1. First and for most: NO INVENTION FOR THE SAKE OF IT.

typedef on a struct is  most of the time just adding syntactical shugar,
and  *deleting* the information that we deal with a struct in case of it's
usage.

This is the kind of code obfuscation which I *hate* even more in C++ or Java.

Many programming language "designers" out there think that making data types
look opaque in usage is a nice thing and a sign of good taste/style. Trust me
they are misguided (read: *idiots*). It is taking valuable information
away (well actually hiding it elswere) for the person looking at the
functional code. I mean the preson looking at the fsck-ing procedural
code which actually *does something*...

2. typedefs for function signature capturing are fine, since there is no other
way to express them sanely.

This is what they where inventid for - just as back doors for things
which couldn't be expressed otherwise. But avoid them where possible,
due to the same reasons as above.

3. typedefs for variable integral entities, which serve a dedicated
puspose are fine, since they:

- Acutally add information to the code where they are used.

- Don't obfuscate the structure of the object in question if you follow rules
1. and 2.

- Allow for differentiation where there are portability issues. size_t is one 
example of justified proper usage in this context.


      reply	other threads:[~2002-04-12 12:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-12 11:47 [PATCH][CFT] IDE TCQ #3 for 2.5.8-pre3 Jens Axboe
2002-04-12 11:55 ` Martin Dalecki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3CB6CB47.8090409@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox