![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Gail Shaw <initialsurname@sentech sa dot com> wrote:
>> Whereas I find the first far too spread out to be able to read easily
>
> Compactness does not imply readability. On the contrary.
>
Case in point:
n=(i<12&&j>=i)?(sqrt(z)*y+j):(y+j*i);
vs
if( i < 12 && j >= i )
{
n = sqrt(z) * y + j;
}
else
{
n = y + j * i;
}
;)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
stbenge wrote:
> Halbert wrote:
>> I, for one, find it much easier to read C++ code which is braced like
>> this:
>>
>> if(somecondition == 0)
>> {
>> // do some stuff
>> }
>> else
>> {
>> // do something else
>> }
>
> I, for more than one, do not.
>
>> As opposed to
>>
>> if(somecondition == 0) {
>> // do some stuff
>> }
>> else {
>> // do something else
>> }
>
> To me, the latter method is much more like POV-Ray than the first
> method. I learned POV first, so I guess that's why I do it.
>
I learned POV first, too. But for C/C++ code, the second example seems
foreign. I much prefer the first example.
But it's kind of like saying you prefer a room painted hunter green,
while I'd prefer forest green.
The only thing I'll say is that if there are coding standards in place,
follow the standard your organization uses.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mike Raiford <mra### [at] hotmail com> wrote:
> Case in point:
> n=(i<12&&j>=i)?(sqrt(z)*y+j):(y+j*i);
Of course spaces could help readability a bit. Like:
n = (i < 12 && j >= i) ? (sqrt(z)*y + j) : (y + j*i);
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Halbert wrote:
> I, for one, find it much easier to read C++ code which is braced like this:
> Why doesn't the rest of the world understand that?
No idea.
Annoying, isn't it??
The other thing that annoys me is Java's insistance on using camal case
but with a lowercase first letter.
lower_case_with_underscores is just fine.
CamalCaseWithoutUnderscores is also fine.
thisIsJustUnspeakablyHorrid!!
EIFFEL_IS_WORSE_IN_THIS_REGARD...
Annoyingly, Haskell copies Java's incorrect use of camal case...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
How about Microsoft's engineers starting the whole Hungarian Notation
convention with Windows programing. (like lpstrFilePath or iRecursion, etc.)
There seems to be no set standard to it. While the intention is good, a
beginner may have wonder why some variables have names like lpszDemung or
lpfnCBack.
--
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mike Raiford wrote:
> The only thing I'll say is that if there are coding standards in place,
> follow the standard your organization uses.
If I worked for an organization, I would definitely change my style. Of
course if I were programming for a living, I would probably go to school
where they would teach me how to write code that people could decipher :)
Sam
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
stbenge wrote:
> Of
> course if I were programming for a living, I would probably go to school
> where they would teach me how to write code that people could decipher :)
Don't count on it! ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Halbert wrote:
> How about Microsoft's engineers starting the whole Hungarian Notation
> convention with Windows programing.
Actually, this makes a lot of sense for C *when done right*.
The point was not to repeat in the variable name the types that you
declared to the compiler. The point was to repeat in the variable name
the types you CANNOT declare to the compiler.
If you have
int line_width;
int line_height;
int page_height;
int line_count;
int pixel_count
the expressions
page_height = line_count * line_height
and
page_height = line_count * line_width
and
pixel_count = page_height * line_width
and
pixel_count = page_height * page_height
are equally type-correct as far as C is concerned, but two are nonsense.
So you declare
int wLineWidth;
int hLineHeight;
int hPageHeight;
int hwPixelCount;
int lineCount;
Then you can write
hPageHeight = hLineHeight * lineCount;
hPageHeight = wLineWidth * lineCount; // Obvious nonsense!
hwPixelCount = hLineHeight * wLineWidth; // Looks good
hwPixelCount = hLineHeight * hPageHeight; // Nonsense!
Even picking nonsense variable names other than the notation will tell
you that it's nonsense. If you see
hSize = count * hQuantity; // Probably OK
wSize = hQuantity * count; // Probably bogus
That was the idea of "Hungarian notation". Not that you should replicate
what the compiler already knows, but distinguish types that the compiler
can't, because you're using a language whose compiler was designed to
fit into a PDP-11's memory.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Halbert wrote:
> How about Microsoft's engineers starting the whole Hungarian Notation
> convention with Windows programing. (like lpstrFilePath or iRecursion, etc.)
> There seems to be no set standard to it. While the intention is good, a
> beginner may have wonder why some variables have names like lpszDemung or
> lpfnCBack.
>
> --
>
>
I do camel case with lowercase leading letters in my code. It's just how
I name functions. Classes, objects, templates, etc get a leading capital
letter, so do most instances of objects in C++.
Last group project class I was in, one teammate complained about it. He
liked code written his way only, and since I was the debugger of the
group he really didn't like my edits. He told me I could use any other
convention I liked, but I was not to state with a leading lowercase
without a reason. I offered to start with lowercase letters for
Hungarian Notation. Very quickly, my normal method of naming was allowed
to remain untouched.
It was sad that I had to explain why I was laughing and he was panicking
to the third member of our group.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
>
> I disagree.
>
Good, 'cause you're wrong.
--
Eero "Aero" Ahonen
http://www.zbxt.net
aer### [at] removethis zbxt net invalid
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |