Reductions in programming

Question

Sometimes to make a variable/method/class name descriptive I need to make it longer. But I don't want to, I'd like to have short names that are easy to read. So I thought of a special addin to IDE like Visual Studio to be able to write short names for class, method, field but be able to attach long names. If you need to - you can make it all long or you can make single name long. If you want to reduce it - use reduction, like two views of the same code. I`d like to know what others thinking about it? Do you think it is usefull? Would anybody use the kind of addin?

Answer 1

A variable name should be as long as required to make it identifiable, does it matter if it's a bit longer than you would prefer? As long as the code is readable and understandable, surely this makes no difference?

Use comments for names that would be far too long to use as a variable/class name. This would be a lot more appropriate.

If a method name is too long, then it shouldn't be a single method...

I wouldn't use an addin like that.

Answer 2

Other programmers without this addin would find themselves in trouble because if you give too short names they will not fully understand the code, if you give long names they will loose time reading and eventually get angry because long names are difficult to remember :P

One has to find the best name for everything one writes, imho there is no need for a switch to turn on and off verbosity for identifiers.

I would not use that addin.

Answer 3

I don't think I'd want it.

The overhead of switching between different views would be as much work as hitting F12 and reading the comment for the function, which will always be more descriptive than the long name.

Answer 4

Why not just use the standard XML commenting system built into Visual Studio. If you type /// above the Class/Method/variable etc, it creates the comment stub. These comments popup through Intelisense/Code Completion with extra info.

This way you keep your naming conventions short and descriptive whilst commenting your code. You can run a process to then create documentation for your code using these comments.

See: http://msdn.microsoft.com/en-us/magazine/cc302121.aspx

Answer 5

I never worry about long names. If a method name becomes too long, it may also indicate that the method does too much (unless it happens to include a really long word). On the other hand, I also try to avoid repeating myself. I would not have Account.AccountId for instance, but rather Account.Id. I also lean back on the namespace; if the namespace is clear about what domain I am in, I usually try to not repeat that in class- or member names.

Bottom line; I can't see myself using such an addin.

Answer 6

I wont.

Long function names could be handy in somecases. If you have a special case or something. Some examples:

what would you favor for multiplication, mul or multiply ? multiply is my choice

Choosing functionnames is a matter of making your code clear for using, if you have too small names and you have to read comment to know what the function does, then youre doing it wrong

Answer 7

Nor I. The fact is you are talking about VisualStudio. It takes the heavy-load of remembering most variables names (long and short) with IntelliSense. As Power said, as long as the code is readable and understandable, that's all that matters.

Answer 8

IDEs, text editors and compilers support limited (if at all limited) form of described functionality - that is source code comments. I think comments do very well and don't see any necessity of described addin. If comments are too long they can be folded. If you need source code with no comments you can easily strip them off with regex of similar stuff.

Answer 9

Id like to have short names that are easy to read.

That is often a contradiction in terms.

Take for example a name like oScBf, if you don't already know what it's for it's practically unreadable. Is it outputScreenBuffer, onlineSourceBitflag, openScannerBrowsefile, outdoorSpecialBikinifavorites...?

Longer identifier names are usually preferrable. Eventhough it's more to read, it's still easier to understand.

Reading code is in some ways similar to reading text. You expect it to follow a certain pattern to be easy to read, if you start to add a lot of abbrev. and non-std words in da text u hav 2 stop n think what it means, and u lose da flow. :)

Answer 10

I like the idea. It's really good and I congradulate you and hope you're successful in developing it. Although I would never use such an Add-On.

Answer 11

It's a bad idea. Variable names don't usually need to be long to be adequately descriptive, you'll waste a lot of time writing two versions of every name, and many programmers will probably find it rather confusing to have multiple names for the same thing.

With XMLDoc and intellisense help, you can add any extra detail required to fully describe a code element - the name doesn't need to describe the minutiae, only give a clear and distinctve idea of what the code element's purpose is.

With name auto-completion readily available, there is no longer any reason to complain of long names requiring lots of typing.

Also, good coding style is all about making code easy to read, understand and maintain, not about packing more code into a smaller space.

OO design should help to break functionality down hierarchically into namespaces and classes, reducing the need for such long names at the class/method level)

Lastly, if you really must shorten names, most languages most languages provide easy ways to strip off namespaces and/or add competely new aliases for names (e.g. 'typedef' and 'using' in C++, 'using' in C#), so in a localised region you can easily refer to a long name via a shortened variant or alias if you wish.