views:

963

answers:

11

As my formal education in programming pre-dates C, I learnt C from K&R and other texts.

Are there helpful conventions for vocalising C code when reading and writing it?

For example, in

 d = emalloc(sizeof(*d));
 d->d_name = estrdup(name);

is '=' best read as 'is set to' or 'equals' or something else?

Would '==' then be read as 'equals' or 'is' or 'has the same value as'?

Similarly with "*d", "d->d_name", and then "&d", " & ", " && ", and so on.

I know what all these mean and what they do, the question relates to what you say (out loud or internally) when reading the symbol, especially if you think this helps understanding and minimises confusion.

+4  A: 

I hadn't really thought about it before, but I now realise that I don't intermally read programming language statements like those above as English words. I just look at them and know what they do.

And interestingly, this works even when I don't really know what a function does. For example, I've never come across emalloc() before, but my brain still tells me what the statement (probably) does.

If for some reason (war? national security?) I had tb read something like:

 d->d_name = estrdup(name);

over the phone, I'd say:

"thing pointed to by d's d_name member gets assigned the result of calling estrdup with name as the parameter"

But that is emphactically not what is going through my head when I read the code.

anon
Close to what I have learnt to do: nice to have it confirmed as an approach used by others.
mas
+1  A: 

I'm not a native english speaker and neither do I read out code, but here's how I'd do it:

= -> equals
== -> is equal to
& -> bitwise and
&& -> and
&d -> address of

I would read *d, d->d_name, d.d_name as "d"/"d d_name", as it should be clear from the context.

tstenner
+7  A: 

I pronounce this as:

d = emalloc(sizeof(*d));

dee equal ee malloc size of star dee

d->d_name = estrdup(name);

dee arrow dee underscore name equal ee stir dupe name"

But I wouldn't call any of that best practice. I don't pronounce the parenthesis except when it would be ambiguous, such as with operator precedence. I do pronounce almost all other punctiation. I actually read == as "equal equal"

TokenMacGuy
+4  A: 

I am not an English native, but those are the terms I see being used the most:

'=' - assign to
'==' - equals
d->d_name member of a struct
&d - address of d
& - bitwise and
&& - logical and (or just "and" for short)
*d - dereference d, or in case of *d = x "assign x to what is being pointed by d"

As for your example:

d = malloc(sizeof(*a));

Allocate (malloc) an amount of memory equal to the size of what is pointed to by a and assign the result to d.

d->d_name = estrdup(name);

Assign to the member d_name of d the value returned by the call to estrdup with name as the parameter.

PaV
+1  A: 

Hmm, never thought about this directly before.

For words and identifiers, I just pronounce them as they are written.

For symbols, I don't think there is a hard and fast rule. If the operator pronounced as it's written makes sense then I do that. For example, == I would pronounce as equals equals. There's no ambiguity there and for most programmers it flows.

Operators like -> though I would just say member access. Saying "dash greater than" is correct but I'm guessing I'd get a few funny stares.

JaredPar
+8  A: 

ASCII Pronunciation Rules for Programmers has a large list of, well, the ASCII pronunciation rules... not so much the best way to pronounce a pointer, necessarily, but at least how to verbalize symbols.

Mark Rushakoff
+1 I like the rules, they might come handy some day. To be honest I've never used pronunciation of any code (pythoh, C, C++, ...). What I'm usually doing is just describing code in words like: allocate 'dee', set the name member in dee...
SashaN
+1  A: 
 d = emalloc(sizeof(*d));

dee equals ee malloc sizeof star dee

 d->d_name = estrdup(name);

dee ref dee name equals ee stir dup name

 if ( d -> d_name == NULL )

if dee ref dee name is null

or

if dee ref dee name is equal to null

Pete Kirkham
+2  A: 

I normally use the word/group of words in which are already used for the C syntax elements if i need to pronounce/read aloud the C code-

e.g.

*d = value at memory address in d

d->d_name = value at memory address pointed at some offset from base address in d (this value could be a integral value or another address value!)

&d = memory address of value d

x=y = value of x updated and changed with value in y.

x == y =compare value of x with value of y

When i was doing this i found that 'pronouncing' following C language constructs would be tricky/interesting:

union
{
  int a;
float b;
}

function pointers,

typecasts,

-AD.

goldenmean
In case anyone's counting, for your three tricky cases I'd say "union open-brace int a semi-colon float b semi-colon close-brace but no semi-colon"; "function taking <whatever: eg an int argc and a char star star argv> and returning <whatever: eg int>"; and "a equals b cast to int" respectively.
Steve Jessop
A: 

what about localization? how would you pronounce this if you were in another country?

+1  A: 

I usually pronounce both "=" and "==" as "equals".

There's little ambiguity, since I very rarely use "=" in a context where its result is used, or "==" in a context where its result is not used. If the former came up, perhaps in code I was reading that I didn't write, I might say "if a single-equals b", or "for i equals j semi-colon i single-equals j semi-colon plus-plus j. I hope that's not a bug".

In any case, it's pretty rare for me to speak code out loud in a context where ambiguity really matters. So how I normally say it is different from what I'd do in a situation where I needed to be really pedantic about conveying text accurately.

If I was dictating a lot of code (pair programming, for example) then I'd normally expect to read it as it was typed, so any errors can be spotted. If my ambiguity was frequently confusing the typist and wasting time, then I'd expect just to agree a convention on the spot. Far easier than forming a consensus among all C/C++/Java/C# programmers in the world, ever.

Steve Jessop
A: 

IMO, here is the best way to read the following (insofar as PHP is concerned):

= "is (now) set to"

== "is (now) equal to"

=== "is (now) identical to"

  • Calling = "is set to" helps to avoid using it incorrectly.
  • The word "now" is optional but reminds programming novices (like myself) of the dynamic nature of values.
abajan