This probably sounds like an obvious one for experienced coders but for me who codes only occasionally AreValid seems to get lost in the code. So I am tempted to use IsValid, as long as the name is in plural form e.g. AreUserInputsValid but what do the naming conventions say?
I think in the most languages it is preferred to use the non-plural notation. So you can define it like IsUserInputValid (Notice Input instead of Inputs).
Input can be considered as a 'group' and therefore can be named as with Is. This goes the same for array/List implementation IsArrayValid, still it can has more than 1 entries, yet you will 'group' it by the name of array.
Related
to is an infix function within the standard library. It can be used to create Pairs concisely:
0 to "hero"
in comparison with:
Pair(0, "hero")
Typically, it is used to initialize Maps concisely:
mapOf(0 to "hero", 1 to "one", 2 to "two")
However, there are other situations in which one needs to create a Pair. For instance:
"to be or not" to "be"
(0..10).map { it to it * it }
Is it acceptable, stylistically, to (ab)use to in this manner?
Just because some language features are provided does not mean they are better over certain things. A Pair can be used instead of to and vice versa. What becomes a real issue is that, does your code still remain simple, would it require some reader to read the previous story to understand the current one? In your last map example, it does not give a hint of what it's doing. Imagine someone reading { it to it * it}, they would be most likely confused. I would say this is an abuse.
to infix offer a nice syntactical sugar, IMHO it should be used in conjunction with a nicely named variable that tells the reader what this something to something is. For example:
val heroPair = Ironman to Spiderman //including a 'pair' in the variable name tells the story what 'to' is doing.
Or you could use scoping functions
(Ironman to Spiderman).let { heroPair -> }
I don't think there's an authoritative answer to this. The only examples in the Kotlin docs are for creating simple constant maps with mapOf(), but there's no hint that to shouldn't be used elsewhere.
So it'll come down to a matter of personal taste…
For me, I'd be happy to use it anywhere it represents a mapping of some kind, so in a map{…} expression would seem clear to me, just as much as in a mapOf(…) list. Though (as mentioned elsewhere) it's not often used in complex expressions, so I might use parentheses to keep the precedence clear, and/or simplify the expression so they're not needed.
Where it doesn't indicate a mapping, I'd be much more hesitant to use it. For example, if you have a method that returns two values, it'd probably be clearer to use an explicit Pair. (Though in that case, it'd be clearer still to define a simple data class for the return value.)
You asked for personal perspective so here is mine.
I found this syntax is a huge win for simple code, especial in reading code. Reading code with parenthesis, a lot of them, caused mental stress, imagine you have to review/read thousand lines of code a day ;(
I want to make a variable that is condiments that the customer wants.
I thought 'condimentCustomerWants' is okay
But I would never see variable name that contains relative pronouns in other's codes.
So I asked to my friends, and he recommended 'customerWantsCondiment', which is sentence.
Hmm.. which name is proper, good, and readable?
I'll throw desiredCondiments into the mix.
Depends on everyone's coding style really. i would do
requestedCondiment
desiredCondiment
preferredCondiment
condimentForCustomer
preferredCondimentForCustomer
wantedCondiment
and so on...
HOW you name your variables is entirely up to you, however they should always reflect what the variable is actually supposed to do.
If it is: 'Does the customer want a condiment', you'd want:
CustomerWantsCondiment (true/false value, probably a boolean)
If it is: 'Which condiment does the customer want?', you'd want:
CondimentCustomerWants (for example an int value)
They sound similar, but both have different meanings.
Whatever works best for you, really.
You may also want to adhere to a variable name convention, starting your variable name with a letter, that indicates the type of the variable. That way, you will know the type of a variable at a glance, without having to look for the actual definition.
Please note, that the introducing letter(s) are always lower case.
For example:
bool bCustomerWantsCondiment;
int iCustomerWantsCondiment;
char *sCustomerWantsCondiment;
etc.
For more information regarding the hungarian notation, please look here for example:
http://en.wikipedia.org/wiki/Hungarian_notation
Also, for readability, you should use the 'CamelCase' convention. That means, each time you begin a new word in the variable name, start it with a capital letter.
What is the right way to name a variable
int numItems;
vs.
int itemCount;
or constant:
public static final int MAX_NUM_ITEMS = 64;
vs.
public static final int MAX_ITEM_COUNT = 64;
In "Code Complete," Steve McConnell notes that "Number" is ambiguous. It could be a count, or an index, or some other number.
"But, because using Number so often
creates confusion, it's probably best
to sidestep the whole issue by using
Count to refer to a total number of sales and Index to refer to a
specific sale."
item_count or itemCount (there's a religious war brewing there, though)
For Java I would use itemCount and MAX_ITEM_COUNT. For Ruby, item_count and MAX_ITEM_COUNT. I tend not to use names that can be interpreted wrongly (numItems may be a shortcut for numerate_items or number_of_items), hence my choice. Whatever you decide, use it constantly.
It's a matter of personal preference, just make sure you are consistent throughout your code. If you're working with others check what's been done in existing code.
For the constant I would find MAX_ITEMS more logical than MAX_NUM_ITEMS or similar, it just sounds better to me.
It actually depends on you. The two types of naming conventions are
camelCase and snake_case
As you can identify from the naming, camel case has one small letter in the initial part of the variable followed by the Capital words
Eg itemCount.
snake case is a continuous word with an underscore ' _ ' in between the words
Eg item_count
As far as the naming is concerned, numItems is quite confusing for others to read. But itemCount is a good name for a counter variable
I've been wondering about this question too, and thought it interesting in all these answers that no one said just items, but I can see that would be a bad name perhaps if it's in a codebase that has objects or arrays, but maybe okay as like a field name in SQL.
But one downside I just realized to going with something like numItems is that if you have multiple similar fields and use anything with intellisense or autocomplete, there's a risk of accidentally using the wrong field, whereas item_count begins with the thing you're counting.
In algebra if I make the statement x + y = 3, the variables I used will hold the values either 2 and 1 or 1 and 2. I know that assignment in programming is not the same thing, but I got to wondering. If I wanted to represent the value of, say, a quantumly weird particle, I would want my variable to have two values at the same time and to have it resolve into one or the other later. Or maybe I'm just dreaming?
Is it possible to say something like i = 3 or 2;?
This is one of the features planned for Perl 6 (junctions), with syntax that should look like my $a = 1|2|3;
If ever implemented, it would work intuitively, like $a==1 being true at the same time as $a==2. Also, for example, $a+1 would give you a value of 2|3|4.
This feature is actually available in Perl5 as well through Perl6::Junction and Quantum::Superpositions modules, but without the syntax sugar (through 'functions' all and any).
At least for comparison (b < any(1,2,3)) it was also available in Microsoft Cω experimental language, however it was not documented anywhere (I just tried it when I was looking at Cω and it just worked).
You can't do this with native types, but there's nothing stopping you from creating a variable object (presuming you are using an OO language) which has a range of values or even a probability density function rather than an actual value.
You will also need to define all the mathematical operators between your variables and your variables and native scalars. Same goes for the equality and assignment operators.
numpy arrays do something similar for vectors and matrices.
That's also the kind of thing you can do in Prolog. You define rules that constraint your variables and then let Prolog resolve them ...
It takes some time to get used to it, but it is wonderful for certain problems once you know how to use it ...
Damien Conways Quantum::Superpositions might do what you want,
https://metacpan.org/pod/Quantum::Superpositions
You might need your crack-pipe however.
What you're asking seems to be how to implement a Fuzzy Logic system. These have been around for some time and you can undoubtedly pick up a library for the common programming languages quite easily.
You could use a struct and handle the operations manualy. Otherwise, no a variable only has 1 value at a time.
A variable is nothing more than an address into memory. That means a variable describes exactly one place in memory (length depending on the type). So as long as we have no "quantum memory" (and we dont have it, and it doesnt look like we will have it in near future), the answer is a NO.
If you want to program and to modell this behaviour, your way would be to use a an array (with length equal to the number of max. multiple values). With this comes the increased runtime, hence the computations must be done on each of the values (e.g. x+y, must compute with 2 different values x1+y1, x2+y2, x1+y2 and x2+y1).
In Perl , you can .
If you use Scalar::Util , you can have a var take 2 values . One if it's used in string context , and another if it's used in a numerical context .
In this question, a user commented to never use the With block in VB. Why?
"Never" is a strong word.
I think it fine as long as you don't abuse it (like nesting)
IMHO - this is better:
With MyCommand.Parameters
.Count = 1
.Item(0).ParameterName = "#baz"
.Item(0).Value = fuz
End With
Than:
MyCommand.Parameters.Count = 1
MyCommand.Parameters.Item(0).ParameterName = "#baz"
MyCommand.Parameters.Item(0).Value = fuz
There is nothing wrong about the With keyword. It's true that it may reduce readibility when nested but the solution is simply don't use nested With.
There may be namespace problems in Delphi, which doesn't enforce a leading dot but that issue simply doesn't exist in VB.NET so the people that are posting rants about Delphi are losing their time in this question.
I think the real reason many people don't like the With keyword is that is not included in C* languages and many programmers automatically think that every feature not included in his/her favourite language is bad.
It's just not helpful compared to other options.
If you really miss it you can create a one or two character alias for your object instead. The alias only takes one line to setup, rather than two for the With block (With + End With lines).
The alias also gives you a quick mouse-over reference for the type of the variable. It provides a hook for the IDE to help you jump back to the top of the block if you want (though if the block is that large you have other problems). It can be passed as an argument to functions. And you can use it to reference an index property.
So we have an alternative that gives more function with less code.
Also see this question:
Why is the with() construct not included in C#, when it is really cool in VB.NET?
The with keyword is only sideswiped in a passing reference here in an hilarious article by the wonderful Verity Stob, but it's worth it for the vitriol: See the paragraph that starts
While we are on identifier confusion. The with keyword...
Worth reading the entire article!
The With keyword also provides another benefit - the object(s) in the With statement only need to be "qualified" once, which can improve performance. Check out the information on MSDN here:
http://msdn.microsoft.com/en-us/library/wc500chb(VS.80).aspx
So by all means, use it.