After discovering (see here and here) that:
"VBA.Len" is not equivalent to "Len"
"VBA.LenB" is not equivalent to "LenB"
"VBA.Mid" is not equivalent to "Mid"
"VBA.Left$" is equivalent to "Left$"
and other confusing things like that:
"Left" and "InStr" are in this official list of keywords while it's not in this other official list of keywords
"InStrRev" and "LenB" don't appear in any official keywords lists while "InStr" and "Len" do appear in one or both lists
I'm left very confused about when to use "VBA." and when not.
Is there a way to obtain a real complete list of the native-internal VBA commands, more reliable than the official documentation?
I mean something like an "object browser" (where I can see the real complete list of the commands in the "VBA." library) for native-internal VBA commands?
The best resource is probably VBE's help and similar on-line, though it's not complete, and doesn't go into the details your raise. Also it doesn't document 'hidden' methods which were once intended to be deprecated but never were, some of which are very useful! Some of your questions were well answered in those other threads, but more generally about your points -
Qualifying with VBA is more about 'where' the method is sourced, and then whether or not there is any difference in the actual method, which in most cases there isn't apart from sourcing. Most of those strings functions are both in the Strings module and in the _HiddenInterface Interface (which is faster).
Left$ though is only in the Strings module, as are similar $ functions, and why you don't notice any difference in performance. Str is both in the _HiddenInterface and Conversion module.
If you're sure the unqualified versions do what you want you might think best to not to qualify, and generally that's fine. But if you ever end up with a project with a MISSING reference, unqualified Strings and DateTime functions will blow before your code has a chance to be alerted. Depending on how deployed or if not sure I tend to fully qualify, eg VBA.Strings.Left$, VBA.DateTime.Date. FWIW as a small bonus you'll get the intellisense.
Related
This is a question with no definite answer so apologies if I posted this wrongly however at my place of work alot of the code I see written by our developers have function names with the keyword 'should', must I add they base this on 'should' and 'should not'. From a point of semantics, whats your view on this? I've mentioned before that I don't believe this should be used because it has too many possibilities (where does it end) however they insist its a good practice.
Example use;
$this->it_should_render_template_partially($params);
$this->it_should_show_module_parameters($params);
$this->it_should_not_return_module_parameters($params);
I am curious on others thoughts. Just to add, this is production code and not unit tests.
While I like long, descriptive, names, I don't like redundancy. When I read the documentation of a function, I expect it to do what it is supposed to do. Yes, functions are written by humans that make a lot of mistakes, so they can have bugs, which means they do not behave as intended. But this is implied when one uses a function. We hope that out functions do what they should (and we try to make sure that is the case using tests). But specifying the should part in the name of a function is just redundant, which is, in my opinion, a bad practice, as it results in longer names, harder to read/write.
are there constant strings for names of build in filters(CIColorControls, CIBloom, etc.) in Mac OS X?
There are constant strings like kCIInputEVKey, which you can use to avoid string literals like #"inputEV", but i can't find something similar for names of filters.
thx in advance!
Yevgeniy.
It's hidden away, but there is a list of names of filters, and what they do:
Core Image Filter Keys - Apple Documentation
As you’ve probably found out already, there aren’t.
While I see that filters can be provided at runtime, so in order to get the full picture you have to query the list of available filters at runtime, I can only guess why there isn’t a canonical set of filters that are guaranteed to exist — after all, that’s what introducing such constants boils down to.
Most (if not all) filters that were introduced in 10.4 are still around, so it’s not too unsafe a bet to rely on them sticking around. That said, you should probably always account for a failed lookup…
I am using HP Exstream (formerly Dialogue from Exstream Software) version 5.0.x. It has a feature to define and save boolean expressions as "Rules".
It has been about 6 years since I used this, but does anybody know if you can define a rule in terms of another rule? There is a "VB-like" language in a popup window, so you are not forced to use the and/or, variable-relational expression form, but I don't have documentation handy. :-(
I would like to define a rule, "NotFoo", in terms of "Foo", instead of repeating the inverse of the whole thing. (Yes, that would be retarded, but that's probably what I will be forced to do, as in other examples of what I am maintaining.) Actually, nested rules would have many uses, if I can figure out how to do it.
I later found that what one needs to do in this case is create user defined "functions", which can reference each other (so long as you avoid indirect recursion). Then, use the functions to define the "rules" (and, don't even bother with "library" rules instead of "inline" rules, most of the time).
I'm late to the question but since you had to answer yourself there is a better way to handle it.
The issue with using functions and testing the result is that there's a good chance that you're going to be adding unnecessary processing because the engine will run through the function every time it's called. Not a big issue with a simple function but it can easily become a problem if the function is complex, especially if it's called in several places.
Depending on the timing of the function (you didn't say whether it was a run level, customer level, or specific to particular documents), it's often better to have the function set a User Boolean variable to store the result then in your library rules you can just check the value of the variable without having to run through the function every time.
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?
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.