Quote:Who suggested not using naming conventions? Or am I misunderstanding?

(summarizing) I was referencing comments made about how naming didn't matter as long as the name had functional relevance -- the IDE could be used to obtain other relevant information such as structure and type. I felt this adovocated using the IDE as a "crutch" in place of functionality a traditional naming convention would provide.

Furthermore, naming based on functional relevance alone is not a naming convention at all because it does not address the issue of consistency, or structure. A comment was also made that naming should be "function not form". Form is the heart of a naming convention, it is the very essence of code consistency.

For example, consider the use of length as a form to naming in addition to functionality descriptions. Using length generilizations alone, you can add scope information to your variables (such as the longer the length the broader the scope, as used in Linux kernel development). Consider capitalization, also a representation of form, can be used to seperate Class names from variable names. Depending on language, framework, etc. prefixes containing meta information, or type should be leveraged when problems are forseeable, it is not redundant to do so, or as a differentiator.

I hope that clarifies why I felt naming conventions were being disregarded.

EDIT:

Quote:Code changes. Hence variable names should reflect the function, not the form. Once a variable is referenced in 500 files, across 20 projects, renaming it simply isn't possible anymore.

My point exactly. Having a variable referenced in 500 files across 20 projects is horrendous. Following a naming convention (such as the one I mentioned with scope) would have prevented this problem becuase longer variable names are inconvinient and as such adherence discourages broad scope. Applying form in this case would have allowed a developer to rethink function...

[Edited by - CowboyNeal on April 28, 2010 12:34:17 PM]

Quote:Original post by CowboyNeal

My point exactly. Having a variable referenced in 500 files across 20 projects is horrendous.

So just about every library is horrendous? Boost, SDL, OpenGL, Linux, WinAPI, TBB, ........, and the list keeps going on and on, ....., MySQL, SQLite, ......

And not just variables, but any identifier.

500 in 20 is not much. Millions in tens of thousands. At least for libraries that are actually used.

I prefer descriptive names, using the actual typename if there is only one instance. I've seen lots of instances lately of stuff like this working with other people's code:


But I prefer



I don't really see any need for Hungarian notation. I think when types get hairy, or dealing with lots of similarly typed objects for different purposes, names like such are better than a simple prefix:

Quote:Original post by CowboyNeal
(summarizing) I was referencing comments made about how naming didn't matter as long as the name had functional relevance -- the IDE could be used to obtain other relevant information such as structure and type. I felt this adovocated using the IDE as a "crutch" in place of functionality a traditional naming convention would provide.

I suppose you could view the IDE as a crutch. The fact is, most IDEs have autocomplete now, and it lets us use more descriptive variables without giving ourselves RSI. For the complete beginner, maybe Intellisense/Autocomplete & what not is bad because it makes things 'too easy' to learn properly; but if you know what you're doing the IDE is indispensable, and valuable because it allows you to write code like

double [] BufferOfIncomingSamples_FromDataSource = new double[this.Parent.GetDataSource().BufferSize_ForCurrentIteration];

in about 16 keystrokes. So it is efficient to use an IDE to help you write clear code - and the afforded clarity will probably prevent bugs down the road.

Quote:Original post by DevFred

Quote:Original post by YogurtEmperor
nothing pisses me off more than not being to immediately recognize the types and scopes of the variables I am seeing.
Types of variables are only one problem, but it is frustrating seeing a value being used and not immediately knowing whether it is a local, a parameter, a member, or, God forbid, a global.

If you cannot tell immediately whether a variable is local to the function, you have a problem: the function is too big. If it does not fit on one screen, it is too big. It does too much. Split it up. I would even argue that functions with more than 10 lines are too big.

Same with classes. If your class has more than, say, 100 lines, it is too big. Remember the single-responsibility principle. Let your class do exactly one thing. If it does multiple things, split it up.

Amen to this.

If you are writing functions which are so big that you can't track the local variables in use then you should refactor it.

I make a point of writing functions where I can see the whole thing on the screen at once; locals a clear, parameters are clear and members are clear. (I avoid globals, infact the 'g' prefix is the only one I'll use because it happens so rarely and it's a mental hint to myself to refactor that).

Frankly, if you've hit functions which are so long you can't see them all on screen you are going to have bigger problems than 'finding the type of a variable' because in scope that big you don't know whats happened to the variable by the time you get to it.

Quote:Original post by szecs

Quote:Original post by djz

Quote:Original post by CowboyNeal
(summarizing) I was referencing comments made about how naming didn't matter as long as the name had functional relevance -- the IDE could be used to obtain other relevant information such as structure and type. I felt this adovocated using the IDE as a "crutch" in place of functionality a traditional naming convention would provide.

I suppose you could view the IDE as a crutch. The fact is, most IDEs have autocomplete now, and it lets us use more descriptive variables without giving ourselves RSI. For the complete beginner, maybe Intellisense/Autocomplete & what not is bad because it makes things 'too easy' to learn properly; but if you know what you're doing the IDE is indispensable, and valuable because it allows you to write code like

double [] BufferOfIncomingSamples_FromDataSource = new double[this.Parent.GetDataSource().BufferSize_ForCurrentIteration];

in about 16 keystrokes. So it is efficient to use an IDE to help you write clear code - and the afforded clarity will probably prevent bugs down the road.

That is very long. I absolutely agree with descriptive names, but you have to keep name short as possible. Maybe it's just me, sometimes I can't see to well, 17" monitor etc, so I have to use 15 font size. In case of that line I have to break the line, or I have to scroll vertically (I hate that). So in the end, too long variable/function names can ruin readability.

Yeah, that was an arbitrary example. SampleBuffer_FromDataSource is probably descriptive enough. I also work on a 19" monitor, but for my 15" laptop I have the option enabled in VStudio which automatically "wraps" lines. Typically if there is a method call within the [] I would break up like

double [] SampleBuffer_FromDataSource =     new double[ this.Parent.GetDataSource().BufferSize_ForCurrentIteration];

I was mostly trying to show that the brevity of Hungarian/etc. has no advantage in terms of typing efficiency; and that IDEs are helpful tools; Perhaps I went overboard :)