Related
I was wondering if it was possible to group lines of code in vba excel, in order to make the view more pleasant. Meaning I have 1000 lines of code and would like to group lines in order to hide/show them. I know this is possible in other coding languages, so I would like to know if it was possible in vba.
Thanks
The short answer is no, not out of the box. There is an open source tool that will be able to do this in a future release http://rubberduckvba.com/
If you have a lengthy procedure you may what to ask yourself if it does more than one thing. As a general rule, a procedure should only do one thing. If you break up each separate "thing" into individual procedures, then you can call each procedure in a parent subroutine. A good book on this is "Clean Code: A Handbook of Agile Software Craftsmanship"
Sub ParentSub()
ChildSub1()
ChildSub2()
End Sub
In addition to breaking code up (refactoring) into smaller logical functions, you can also break them across different modules if the Private/Public setting allows it.
If your code is in a class (or in a worksheet), then you can also use Friend for your functions/subroutines.
Of course, once refactored, I often find that I build classes to make my code simpler and easier to maintain. This allows you to hide (encapsulate) much of your lower level code and your main program is now at a much higher level and sometimes almost (if you squint hard enough and you have named your classes and methods properly) look like readable English!
As an aside, the Call keyword is not recommended unless the called expression does not start with an identifier (MSDN ref). In the answer above, the following will work quite fine.
Sub ParentSub()
ChildSub1()
ChildSub2()
End Sub
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
How can I train myself to give better variable and function names (any user-defined name in a program).
Practice.
Always be thinking about it whenever you write or read code, including other people's code. Try to figure out what you would do differently in their code and talk to them about it, when possible (but don't harp on it, that would be a nuisance). Ask them questions about why they picked a certain name.
See how well your code reads without comments. If you ever need to comment on the basic purpose of something you named, consider whether it could have a better name.
The biggest thing is active mental participation: practice.
Thinking of names seems to be something that some people are extraordinarily bad at, and I'm not sure what the cure is. Back when I was an instructor working in commercial training, I'd often see situations like this:
Me: OK, now you need to create an integer variable to contain the value returned by getchar().
[Trainees start typing, and I wander round the training room. Most are doing fine, but one is sitting like a deer frozen the headlights]
Me: What's the problem?
Him: I can't think of a name for the variable!
So, I'd give them a name for it, but I have a feeling that people with this problem are not going to go far in programming. Or perhaps the problem is they go too far...
This is a subjective question.
I strive to make my code align with the libraries (or, at the least the standard ones) so that the code has an uniformity. I'd suggest: See how the standard library functions are named. Look for patterns. Learn what different naming conventions exist. See which one makes the most sense. E.g: most Java code uses really big identifier names, Camel casing etc. C uses terse/short names. There is then the Hungarian notation -- which was worth the trouble when editors weren't smart enough to provide you with type information. Nowadays, you probably don't need it.
Joel Spolsky wrote a helpful article on Hungarian notation a few years back. His key insight is this:
Let’s try to come up with a coding
convention that will ensure that if
you ever make this mistake, the code
will just look wrong. If wrong code,
at least, looks wrong, then it has a
fighting chance of getting caught by
someone working on that code or
reviewing that code.
He goes on to show how naming variables in a rigourous fashion can improve our code. The point being, that avoiding bugs has a quicker and more obvious ROI than making our code more "maintainable".
Read some good code and imitate it. That's the universal way of learning anything; just replace "read" and "code" with appropriate words.
A good way to find expressive names is starting with a textual description what your piece of software actually does.
Good candidates for function (method) names are verbs, for classes nouns.
If you do design first, one method is textual analysis.
(Even if you are only a team of 1) agree a coding standard with your colleagues so you all use the same conventions for naming. (e.g. It is common to use properties for values that are returned quickly, but a GetXXX or CalculateXXX method for values that will take time to calculate. This convention gives the caller a much better idea about whether they need to cache the results etc). Try to use the same names for equivalent concepts (e.g. Don't mix Array.Count and List.Length as Microsoft did in .net!)
Try to read your code as if somebody else wrote it (i.e. forget everything you know and just read it). Does it make sense? Does it explain everything they need to know to understand it? (Probably not, because we all forget to describe the stuff we "know" or which is "obvious". Go back and clarify the naming and documentation so that someone else can pick up your code file and easily understand it)
Keep names short but descriptive. There is no point writing a whole sentence, but with auto-completion in most IDEs, there is also little point in abbreviating anything unless it's a very standard abbreviation.
Don't waste characters telling somebody that this string is a string (the common interpretation of hungarian notation). Use names that describe what something does, and how it is used. e.g. I use prefixes to indicate the usage (m=member, i=iterator/index, p=pointer, v=volatile, s=static, etc). This is important information when accessing the variable so it's a useful addition to the name. It also allows you to copy a line of code into an email and the receiver can understand exactly what all the variables are meant to do - the difference in usage between a static volatile and a parameter is usually very important.
Describe the contents of a variable or the purpose of a method in its name, avoiding technical terms unless you know that all the readers of your code will know what those terms mean. Use the simplest description you can think of - complex words and technical terms sound intelligent and impressive, but are much more open to misinterpretation (e.g. off the top of my head: Collation or SortOrder, Serialise or Save - though these are well known words in programming so are not very good cases).
Avoid vague and near-meaningless terms like "value", "type". This is especially true of base class properties, because you end up with a "Type" in a derived class and you have no idea what kind if type it is. Use "JoystickType" or "VehicleType" and the meaning is immediately much clearer.
If you use a value with units, tell people what they are in the name (angleDegrees rather than angle). This simple trick will stop your spacecraft smashing into Mars.
For C#, C++, C in Visual Studio, try using AtomineerUtils to add documentation comments to methods, classes etc. This tool derives automatic documentation from your names, so the better your names are, the better the documentation is and the less effort you need to put in the finish the documentation off.
Read "Code Complete" book, more specifically Chapter 11 about Naming. This is the checklist (from here, free registration required):
General Naming Considerations
Does the name fully and accurately describe what the variable represents?
Does the name refer to the real-world problem rather than to the programming-language solution?
Is the name long enough that you don't have to puzzle it out?
Are computed-value qualifiers, if any, at the end of the name?
Does the name use Count or Index instead of Num?
Naming Specific Kinds Of Data
Are loop index names meaningful (something other than i, j, or k if the loop is more than one or two lines long or is nested)?
Have all "temporary" variables been renamed to something more meaningful?
Are boolean variables named so that their meanings when they're True are clear?
Do enumerated-type names include a prefix or suffix that indicates the category-for example, Color_ for Color_Red, Color_Green, Color_Blue, and so on?
Are named constants named for the abstract entities they represent rather than the numbers they refer to?
Naming Conventions
Does the convention distinguish among local, class, and global data?
Does the convention distinguish among type names, named constants, enumerated types, and variables?
Does the convention identify input-only parameters to routines in languages that don't enforce them?
Is the convention as compatible as possible with standard conventions for the language?
Are names formatted for readability?
Short Names
Does the code use long names (unless it's necessary to use short ones)?
Does the code avoid abbreviations that save only one character?
Are all words abbreviated consistently?
Are the names pronounceable?
Are names that could be mispronounced avoided?
Are short names documented in translation tables?
Common Naming Problems: Have You Avoided...
...names that are misleading?
...names with similar meanings?
...names that are different by only one or two characters?
...names that sound similar?
...names that use numerals?
...names intentionally misspelled to make them shorter?
...names that are commonly misspelled in English?
...names that conflict with standard library-routine names or with predefined variable names?
...totally arbitrary names?
...hard-to-read characters?
If you were to invent a new language, do you think primitive datatypes should be capitalized, like Int, Float, Double, String to be consistent with standard class naming conventions? Why or why not?
By "primitive" I don't mean that they can't be (or behave like) objects. I guess I should have said "basic" datatypes.
If I were to invent a new language, it wouldn't have primitive data types, just wrapper objects. I've done enough wrapper-to-primitive-to-wrapper conversions in Java to last me the rest of my life.
As for capitalization? I'd go with case-sensitive first letter capitalized, partly because it's a convention that's ingrained in my brain, and partly to convey the fact that hey, these are objects too.
Case insensitivity leads to some crazy internationalization stuff; think umlauts, tildes, etc. It makes the compiler harder and allows the programmer freedoms that don't result in better code. Seriously, you think there's enough arguments over where to put braces in C... just watch.
As far as primitives looking like classes... only if you can subclass primitives. Don't assume everyone capitalizes class names; the C++ standard libraries do not.
Personally, I'd like a language that has, for example, two integer types:
int: Whatever integer type is fastest on the platform, and
int(bits): An integer with the given number of bits.
You can typedef whatever you need from that. Then maybe I could get a fixed(w,f) type (number of bits to left and right of decimal, respectively) and a float(m,e). And uint and ufixed for unsigned. (Anyone who wants an unsigned float can beg.) And standardize how bit fields are packed into structures. If the compiler can't handle a particular number of bits, it should say so and abort.
Why, yes, I program embedded systems and got sick of int and long changing size every couple years, how could you tell? ^_-
(Warning: MASSIVE post. If you want my final answer to this question, skip to the bottom section, where I answer it. If you do, and you think I'm spouting a load of bull, please read the rest before trying to argue with my "bull.")
If I were to make a programming language, here are a few caveats:
The type system would be more or less Perl 6 (but I totally came up with the idea first :P) - dynamically and weakly typed, with a stronger (I'm thinking Haskellian) type system that can be imposed on top of it.
There would be a minimal number of language keywords. Everything else would be reassignable first-class objects (types, functions, so on).
It will be a very high level language, like Perl / Python / Ruby / Haskell / Lisp / whatever is fashionable today. It will probably be interpreted, but I won't rule out compilation.
If any of those (rather important) design decisions don't apply to your ideal language (and they may very well not), then my following (apparently controversial) decision won't work for you. If you're not me, it may not work for you either. I think it fits my language, because it's my language. You should think about your language and how you want your language to be so that you, like Dennis Ritchie or Guido van Rossum or Larry Wall, can grow up to make bad design decisions and defend them in retrospect with good arguments.
Now then, I would still maintain that, in my language, identifiers would be case insensitive, and this would include variables, functions (which would be variables), types (which would also be variables, both built-in/primitive (which would be subclass-able) and user-defined), you name it.
To address issues as they come:
Naming consistency is the best argument I've seen, but I disagree. First off, allowing two different types called int and Int is ridiculous. The fact that Java has int and Integer is almost as ridiculous as the fact that neither of them allow arbitrary-precision. (Disclaimer: I've become a big fan of the word "ridiculous" lately.)
Normally I would be a fan of allowing people to shoot themselves in the foot with things like two different objects called int and Int if they want to, but here it's an issue of laziness, and of the old multiple-word-variable-name argument.
My personal take on the issue of underscore_case vs. MixedCase vs. camelCase is that they're both ugly and less readable and if at all possible you should only use a single word. In an ideal world, all code should be stored in your source control in an agreed-upon format (the style that most of the team uses) and the team's dissenters should have hooks in their VCS to convert all checked out code from that style to their style and vice versa for checking back in, but we don't live in that world.
It bothers me for some reason when I have to continually write MixedCaseVariableOrClassNames a lot more than it bothers me to write underscore_separated_variable_or_class_names. Even TimeOfDay and time_of_day might be the same identifier because they're conceptually the same thing, but I'm a bit hesitant to make that leap, if only because it's an unusual rule (internal underscores are removed in variable names). On one hand, it could end the debate between the two styles, but on the other hand it could just annoy people.
So my final decision is based on two parts, which are both highly subjective:
If I make a name others must use that's likely to be exported to another namespace, I'll probably name it as simply and clearly as I can. I usually won't use many words, and I'll use as much lowercase as I can get away with. sizedint doesn't strike me as much better or worse than sized_int or SizedInt (which, as far as examples of camelCase go, looks particularly bad because of the dI IMHO), so I'd go with that. If you like camelCase (and many people do), you can use it. If you like underscores, you're out of luck, but if you really need to you can write sized_int = sizedint and go on with life.
If someone else wrote it, and wanted to use sized_int, I can live with that. If they wrote it and used SizedInt, I don't have to stick with their annoying-to-type camelCase and, in my code, can freely write it as sizedint.
Saying that consistency helps us remember what things mean is silly. Do you speak english or English? Both, because they're the same word, and you recognize them as the same word. I think e.e. cummings was on to something, and we probably shouldn't have different cases at all, but I can't exactly rewrite most human and computer languages out there on a whim. All I can do is say, "Why are you making such a fuss about case when it says the same thing either way?" and implement this attitude in my own language.
Throwaway variables in functions (i.e. Person person = /* something */) is a pretty good argument, but I disagree that people would do Person thePerson (or Person aPerson). I personally tend to just do Person p anyway.
I'm not much fond of capitalizing type names (or much of anything) in the first place, and if it's enough of a throwaway variable to declare it undescriptively as Person person, then you won't lose much information with Person p. And anyone who says "non-descriptive one-letter variable names are bad" shouldn't be using non-descriptive many-letter variable names either, like Person person.
Variables should follow sane scoping rules (like C and Perl, unlike Python - flame war starts here guys!), so conflicts in simple names used locally (like p) should never arise.
As to making the implementation barf if you use two variables with the same names differing only in case, that's a good idea, but no. If someone makes library X that defines the type XMLparser and someone else makes library Y that defines the type XMLParser, and I want to write an abstraction layer that provides the same interface for many XML parsers including the two types, I'm pretty boned. Even with namespaces, this still becomes prohibitively annoying to pull off.
Internationalization issues have been brought up. Distinguishing between capital and lowercase umlautted U's will be no easier in my interpreter/compiler (probably the former) than in my source code.
If a language has a string type (i.e. the language isn't C) and the string type supports Unicode (i.e. the language isn't Ruby - it's only a joke, don't crucify me), then the language already provides a way to convert Unicode strings to and from lowercase, like Perl's lc() function (sometimes) and Python's unicode.lower() method. This function must be built into the language somewhere and can handle Unicode.
Calling this function during an interpreter's compile-time rather than its runtime is simple. For a compiler it's only marginally harder, because you'll still have to implement this kind of functionality anyway, so including it in the compiler is no harder than including it in the runtime library. If you're writing the compiler in the language itself (and you should be), and the functionality is built into the language, you'll have no problems.
To answer your question, no. I don't think we should be capitalizing anything, period. It's annoying to type (to me) and allowing case differences creates (or allows) unnecessary confusion between capitalized and lowercased things, or camelCased and under_scored things, or other sets of semantically-distinct-but-conceptually-identical things. If the distinction is entirely semantic, let's not bother with it at all.
Most languages give guidelines to separate different words of a name by underscores (python, C etc.) or by camel-casing (Java). However the problem is when to consider the names as separate. The options are:
1) Do it at every instance when separate words from the English dictionary occur e.g. create_gui(), recv_msg(), createGui(), recvMsg() etc.
2) Use some intuition to decide when to do this and when not to do this e.g. recvmsg() is OK, but its better to have create_gui() .
What is this intuition?
The question looks trivial. But it presents a problem which is common and takes at least 5 seconds for each instance whenever it appears.
I always do your option 1, and as far as I can tell, all modern frameworks do.
One thing that comes to mind that just sticks names together is the standard C library. But its function names are often pretty cryptic anyway.
I'm probably biased as an Objective-C programmer, where things tend to be quite spelled out, but I'd never have a method like recvMsg. It would be receiveMessage (and the first parameter should be of type Message; if it's a string, then it should be receiveString or possibly receiveMessageString depending on context). When you spell things out this way, I think the question tends to go away. You would never say receivemessage.
The only time I abbreviate is when the abbreviation is more clear than the full version. createGUI is good because "GUI" (gooey) is the common way we say it in English. createGraphicalUserInterface is actually more confusing, so should be avoided.
So to the original question, I believe #1 is best, but coupled with an opposition to unclear abbreviations.
One of the most foolish naming choices ever made in Unix was creat(), making a nonsense word to save one keystroke. Code is written once and read many times, so it should be biased towards ease of reading rather than writing.
For me, and this is just me, I prefer to follow whatever is conventional for the language, thus camelCase for Java and C++, underscore for C and SQL.
But whatever you do, be consistent within any source file or project. The reader of your code will thank you; seeing an identifier that is inconsistent with most others makes the reader pause and ask "is something different going on with this identifier? Is there something here I should be noticing?"
Or in other words, follow the Principal of Least Surprise.
Edit: This got downmodded why??
Just follow coding style, such moments usually well described.
For example:
ClassNamesInCamelNotaionWithFirstLetterCapitalized
classMethod()
classMember
CONSTANTS_IN_UPPERCASE_WITH_UNDERSCORE
local_variables_in_lowercase_with_underscores
Do languages become more verbose as they mature? It feels like each new version of VB.net gains more syntax. Is it possible to trim down some fat like the keyword "Dim"? C# also feels like it is getting more syntax since version 1.
C# has certainly gained more syntax, but in a way which makes it less verbose.
Virtually every feature in C# 3.0 allows you to do more with less code.
That's the VB idiom. All languages have an idiom, and there are plenty that go for verbose and spelled-out. Thank your lucky stars you're not WRITING IN COBOL.
C# evolved out of the C-like languages, and in the C tradition brevity and terseness are valued, hence braces, && and ||, int not integer, case-sensitive lower-cased code. In the VB idiom, long self-explanatory keywords are good, terse keywords or cryptic symbols are bad, hence MustInherit, Dim blah as Integer and case insensitivity but with a tendency to Capitalise Your Keywords. Basically, stick with the idiom of the language you're using. If you use (or have to use) VB, then get used to the verbosity - it's intentional.
There's nothing wrong with verbosity, in fact it often can be a very good thing.
I assume you have meaningful variable names? Descriptive method names? Then why is there a problem with typing 'end if' instead of '}'. Its really not an issue at all, if anything, the terseness of C# is more of a problem trying to fit as much as possible into as few characters as possible - that means it harder to read, not easier.
Okay... this feels embarrassing to admit, but I like the use of Dim in VB.NET. Yes, it's not serving any particular use that couldn't be inferred by the use of "As" later... but to me, there's something absolutely "beat you over the head" obvious about having declaration statements start with Dim. It means when someone's looking through the code, they don't even have to think about what those statements mean, even for a microsecond. Languages like C# have declarations that are obvious enough, but if you're just browsing by it you may have to consider it for a moment (even the most brief of moments).
There's something "extra obvious" about having a special keyword at the start of certain kinds of statements. In VB.NET, assignments start with "Dim" and calls to methods (can) start with "Call", giving them a kind of "left side uniformity" that If, For, and other constructs already have: you get the barest gist of what's going on with that line just by looking at the very start of it. Using these almost gives you the equivalent of a left-hand column that you can browse down extremely quickly and get the gist of what's going on on some kind of basic level ("Okay, we're declaring things here... we're calling to other things here...").
That might seem irrational or even silly to some people... but it does make the purpose of each statement explicit enough that it feels faster (at least to me) to browse through... especially when browsing through unfamiliar code written by others.
I guess, in the end, it comes down to "different strokes for different folks". I don't mind typing the extra three characters for that obviousness of purpose.
VB.NET is great as it is, it brings more clarity in code.
For instance I love the fact how you can describe what your ending.
End while vs }
End for vs }
End if vs }
And really the verbosity isn't an issue while typing because of intellisence.
Verbosity and readability often go hand-in-hand. Lately I've come to fear the word "Elegant", because it generally translates into "Fun but less immediately readable"
Of course the person writing the code always says "Well it's MORE readable to me because it's shorter/more elegant.
that's crap. It's always easier to read something more explicit unless you have so much trouble reading that it takes you two hours to get through a Dick and Jane novel.
Note that I'm not talking about redundancies, just being explicit and spelling out your desires.
As a programmer it's much MUCH more fun to write elegant expressions, but I've found myself looking at the "elegance" of others and even my own "elegance" after a while and I'll change it to something more explicit, readable and reliable when I realize that although it was fun to write, I just spent more time reading/debugging it than it took to write in the first place.
On the other hand, DIM is just stupid :)
I'm slightly out of my depth here.
I like what everyone calls verbose. Does no one ever wonder my we don't have multiple nested parenthesis in any natural languages (e.g. English)? In fact nested parenthesis really need the convention of indentation to make then legible at all. In natural languages we use verbose clauses and multiple sentences, to avoid, or at least explain layering parenthesis.
Also in a certain sense I wouldn't say vb has much more syntax than c# at all. It doesn't really have many more lexical tokens in a certain block of code than would c# (Does it?). It has about the same syntax as c# it just has longer syntactical tokens, 'End Sub' instead of '}' for example. For most pieces of syntactical plumbing, the VB version will just be more typing (if you are sworn off intelisense), Also '}' is ambiguous compared to 'End Sub' since it also means 'End If' and whole load of other things. This doesn't make it more concise in a certain sense, There are still the same number of tokens in the code, but from a smaller subset of more curt token markers. But different tokens in C# have different meanings depending on the context, which requires you still to have that nested level in your mind as you read the code, in order to get, for example what kind of code block you are reading if you lose your place, even though the end of the code block could be in view you might have to look up to see the beginning of the code block. Even where this is not the case is && really better than AndAlso?
Dim I suppose is quite useless, an extra lexical token compared to c#, but I suppose at least it's consistent with linq, vb doesn't need the var command. I can't think of any other candidates for the chop. Maybe I don't have the imagination.
I'm sure someone is going to come along and tell me how wrong I am :) My best guess this is to do with personal preference anyway.
Then C# should get rid of ";" at the end of every fricking line :)
Default should be easy way to go such "New Line" instead of a ";" if you want exceptions such 2 statements in the same line then you need use a separator such as ":" or ";"
Some people like that. I suspect things like Dim are left in for legacy reasons as much as anything else.
VB does have some nice short cuts though. For example the conversion routines. Eg CInt, CStr etc
OK I'm an old C programmer that came to .Net via C#, and Now I'm working in VB.Net
I have to say at first I was appalled by the verbosity, but having gone back to
C# for I bit, I have to admit I like VB.Net a bit more now.
I can write VB code that reads better and is less cryptic and it really doesn't take
up much more space (especially if you put all your C# curly braces on their own line)
Also the editor in Visual Studio takes care of most of the verbosity for me.
I like how Dim X As List(Of SomeType) reads as opposed to List<sometype> X
Semi-colons are a nuisance now. Curly braces are annoying.
I do miss the square brackets for array refs, a little bit though.
Ever since I saw this...
lowercase keywords?
...I've been hoping it would get included in the language. It's amazing how much more readable it is Without All The Capitalized Keywords.
C# is not a user-friendly language and takes many MORE lines of code to accomplish the same task as VB.Net. Optional parameters, with/end with, etc. are not supported within C#. Even db connections take more code in C#. Star Wars fans love the C# though, as you get to talk like Yoda while you're programming.
My $0.02: VB.Net's intellisense features, shortcuts, logical readability, etc. make it a superior language.
Yes I know what you mean, it can get a bit long winded, I find it becomes hard to read due to there being to too many keywords and making it hard to see the logic behind it all but hey some people like it.
I have just recently started writing all my stuff in C# and I must say I have come to like it a lot more since I just cut of VB and said right C# from now on, so if you are that worried your could always just switch.
Use a pre-processor... and loose any hope to be read by anybody else (or yourself in some years, perhaps...).
I will answer what is often answered to people complaining that Lua is verbose: if you want a concise language, you know where to find it. There are tons of languages around, even if you restrict yourself to the CLR, so why complain about the one you chose? (I know, you might work on a project you didn't started, etc.).
That's not a flame or something. There are many languages for a reason. Some like them super-concise, close of mathematical notations, others like them (more or less) verbose, finding that more readable. There are languages for all tastes!
for one thing that i don't like about VB is this
print("ByVal sender as object, ByVal e as EventArgs");
vs C#
object sender, Eventargs e
Doing so will only make your code harder to read.