Re: Finding variables in source code

Jack, W8TEE
 

It depends. I use i, j, and index quite often in my code and find nothing wrong with it because those variables are almost always used for the same purpose and are rarely the source of program bugs. Everyone has their own coding style...unless you work as a programmer where style is dictated. Personally, I never use an underscore in a variable name for two reasons: 1) double-underscores were typically used as system variables and I still think that when I see them (it's a personal problem), and 2) while I can probably type 70wpm, the underscore key slows me down because I rarely use it. Some coding conventions I've found useful:

    1. Start variable names with a lowercase letter, and only cap the first letter of sub-words: keyboardInput, xmitSwitchState, ptrSisters.
    2. Start function names with an uppercase letter. That way you can tell in a glance whether it's a variable or a function. That's especially useful when you use pointer to         functions.
    3. Variables are like nouns in a sentence. Typically they reflect something of interest in the program and the name should convey that.
    4. Make the name long enough to convey that interest, but short enough you don't find it burdensome to type it over and over.
    5. Function are like verbs in a sentence. Typically they reflect an action taken and the function name should reflect the action, but not the means of the action. That is,         SortList() is a better name than BubbleSortList() because the former says what's to be done, while the latter says what's to be done and here's how I'm going to do it.
        a. Functions are black boxes with no windows. It's nobody else's business what goes on inside. What happens in functions stays in functions. Do you really want to force             users to recode their programs because you stopped using a Bubble Sort and switched to a Shell Sort? Hint: NO.
    6. Make functions cohesive. It you cannot say what a function does in two sentences, it's probably trying to do too many things. Break it into two smaller, and probably more         reusable, functions. Beginning students too often try to write Swiss Army Knife functions; they do a lot, but nothing well. Rarely is a function with a long parameter list a         cohesive function. Passing in flag variables is a dead giveaway that you're trying to make the function do too many things.
    7. Learn how to read and use complex data definitions. For example, what does this definition define:

                double (*(*pf)())[3][4];

        It's easier than you think to figure this out using the Right-Left Rule. (See:http://jdurrett.ba.ttu.edu/3345/handouts/RL-rule.html) Because C allows you to "create" new data types, it's an extremely robust and power language.

Writing C code is a personal thing and everyone is free to write it anyway they want as long as the compiler can parse it. However, when you know someone else has to read it, clarity starts to gain importance and style plays a part, too.

Jack, W8TEE

On Monday, July 16, 2018, 11:13:12 PM EDT, Jon Titus, KZ1G <tituskz1g@...> wrote:


The problem with how to locate variables also involves how programmers label them.  Too many books, teachers, and hobbyists use nonsense variables such as i, j, index, ptr, and so on as variable names.  Use variable names that indicate how you use them--Keyboard_Input, XMIT_Switch_State--and you save yourself and others endless searches and wasted time.
--
Jon Titus, KZ1G
Herriman, UT USA

Join BITX20@groups.io to automatically receive all group messages.