>>9
Your name is hardly any better, it isn't very descriptive, it's like FILE * file, of course it's a fucking file, but what is it used for?
Name:
Anonymous2012-05-26 19:08
>>11
It's a lot better. An 'f' could be anything, whereas a 'stream' is, well, a stream. What else would you call it?
Name:
Anonymous2012-05-26 19:50
>>12
not that dude, but if the FILE* is a local variable to a function that is initialized to a call to fopen, then I name the variable in accordance to what is stored in the file, or what will be written to the file. If the FILE* is just a parameter to some generic printing or reading function for a data type, then I'll either name the parameter input or output, depending on if data is being read or written to it.
this is all pedantic of course.
Name:
Anonymous2012-05-26 22:04
I use:
ALL_CAPS for preprocessor constants
some_name for local symbols
First_letter for symbols of function types
_some_name for global symbols
_, __, ___, ... for symbols that should not be used
__name_ for symbols that are deferred by a typedef
name_ for volatile symbols
as for the naming itself:
name_t for types
name_p for pointer types
name_c for types that are part of a bigger type
multiple_words for symbols with multiple words
CamelCase if the symbol is something that implements some OOP principles
camelCase if the symbol is a type of the above OOP implementation
i, j, k, l for generic cycles
ret for a local symbol to hold the return value
s, r, t for generic strings
file_name for most local symbols, the meaning is interesting on the local scope only
>>12
>It's a lot better. An 'f' could be anything, whereas a 'stream' is, well, a stream. What else would you call it?
Better is finp as in input file pointer. A variable with trivial scope deserves a trivial name.
Name:
Anonymous2012-05-27 15:26
>>16
>finp
Abbreviations are not universally intuitive. I'm sure most people know what an ID is but "finp" is undescriptive. "stream" is still better. If you ever need to have an input and output stream (say you're writing a function that reads from one stream and writes to another), you can just call them "istream" and "ostream". Anyone reading the code immediately knows that both of them are streams, and can hence deduce that one is an input stream and the other an output stream.
>>13
That makes sense, so long as you name them intuitively.