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 3 years ago.
Improve this question
I need a good variable name for a boolean value that returns false when an object is the last in a list.
The only decent name I can come up with is 'inFront', but I don't think that is descriptive enough.
Another choose would be 'isNotLast'. This is not good practice though (Code Complete, page 269, Use positive boolean variable names).
I am aware that I could change the variable definition. So true is returned when an object is the last and call the variable 'isLast', however, it would make this task easier if I had the first explanation.
isBeforeTheLastItem
isInFrontOfTheLastItem
isTowardsTheFrontOfTheList
Maybe too wordy but they may help give you ideas.
My vote would be to name it IsLast and change the functionality. If that isn't really an option, I'd leave the name as IsNotLast.
I agree with Code Complete (Use positive boolean variable names), I also believe that rules are made to be broken. The key is to break them only when you absoluately have to. In this case, none of the alternative names are as clear as the name that "breaks" the rule. So this is one of those times where breaking the rule can be okay.
hasFollowingItems? or hasFollowingXXXXs where XXXX is whatever the item in your list is?
Personally more than anything I would change the logic, or look at the business rules to see if they dictate any potential naming.
Since, the actual condition that toggles the boolean is actually the act of being "last". I would say that switching the logic, and naming it "IsLastItem" or similar would be a more preferred method.
isPenultimateOrPrior
isBeforeEnd
Haskell uses init to refer to all but the last element of a list (the inverse of tail, basically); would isInInit work, or is that too opaque?
How about:
hasSiblings
or isFollowedBySiblings (or isFolloedByItems, or isFollowedByOtherItems etc.)
or moreItems
Although I think that even though you shouldn't make a habit of braking 'the rules' sometimes the best way to accomplish something may be to make an exception of the rule (Code Complete guidelines), and in your case, name the variable isNotLast
A simple semantic name would be last. This would allow code always positive code like:
if (item.last)
...
do {
...
} until (item.last);
Two issues to think about
What is the scope of the variable (in other words: are you speaking about a local variable or a field?) ?
A local variable has a narrower scope compared to a field. In particular, if the variable is used inside a relatively short method I would not care so much about its name. When the scope is large naming is more important.
I think there's an inherent conflict in the way you treat this variable. On the one hand you say "false when an object is the last in a list", where on the other hand you also want to call it "inFront". An object that is (not) last in the list does not strike me as (not) inFront. This I would go with isLast.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Assume that I have a subfunction seen in the below. What is the difference between these two
function a=b(x,y)
.
.
.
a=output
and
function b(x,y)
......
if I write it in second form how can I define it main function and how can I see its outputs.
Another question,
I found a code from here (http://www.mathworks.com/matlabcentral/fileexchange/21443-multiple-rapidly-exploring-random-tree--rrt-) including a function like:
%% SetObstacleFilename
function SetObstacleFilename(self,value)
if isa(value,'char')
self.obstacleFilename = value;
self.GenerateObstacles();
end
end
how can I use it in my main function? Moreover what is self.GenerateObstacles() command? There is no equality on it?
I think I see how both of your questions are related to the same thing. You really should've asked something along the lines of:
I always saw MATLAB functions written in the form function a=b(x,y), however recently I came across some code which included functions in the form function b(x,y) (e.g. function SetObstacleFilename(self,value)).... so what's up with that?
In order to understand the 2nd type of functions, you need to consider object-oriented programming (OOP).
The code example you found is taken from within a MATLAB class. Class-related functions are known in OOP as "methods", and this specific code in another programming language would take the shape of a void return type function\method.
Now consider the term object that refers to an instance of a class.
Traditionally, methods are limited to a single output. For this reason, some methods are designed to operate on objects (actually pointers, AKA "passing by reference") such that returning a value is not necessary at all, because the input objects are directly manipulated. Other cases when methods don't need to return anything may include functions that have some "utility" functionality (e.g. initialize something, plot something, output something to the console etc. - just like the self.GenerateObstacles() method you mentioned).
Regarding your other questions:
The self in SetObstacleFilename(self,value) looks like an instance of the considered class.
Usually to use class methods you need to instantiate an object using a constructor (which should be a function with the same name of the class), unless these methods are static.
To conclude - above are just the most fundamental basics of OOP. I won't attempt to teach you the whole OOP Torah while standing on one leg, so I am providing some additional materials below, should you be interested to further your understanding of the topic.
Hopefully, what's going on is a bit clearer now!
Here are some resources for you:
MATLAB's OOP Manual.
MATLAB's documentation on OOP.
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
I'm pretty much a noob with Unity. As a c++ programmer, the naming conventions in Unity bothers me a little. And having OCD ontop of that makes me go crazy ;)
The objects has say a property Transform which again has a property Position.
But these properties must be accessed by writing transform.position in the code using lower case. This is not very intuitive to me. So I wonder how I can look at it in order to more easily avoid complications. And what conventions I should use to be able to tell everything appart by taking a quick look at the variables.
The Unity convention is actually rather simple: everything is Pascal-cased, types (classes, structs, enums) and methods start with upper-case, fields and properties with lower-case. Enum values in upper-case, constants in lower-case (usually).
So ClassName, MethodName, myField, myProperty { get; set; }, MyEnum.CaseA... that's it.
As for your example, Transform is a class, whereas transform is an accessor to the instance of Transform in that particular GameObject/Component.
Also, Transform doesn't have a Position property, it has a position property (always lower-case).
This is more or less based on C#'s conventions and the standard .NET library (MS has very precise guidelines about it), except standard .NET uses UpperCase for public/protected methods AND properties, and lower-case for private (again, usually; what's private is more left to the taste of the coder I think).
As a side-note, with any codebase, in any language, the best way is ALWAYS to follow the existing convention. Every seasoned programmer will tell you this. I understand about OCD, believe me, but in this case I suggest you let it go.
There are very little objective arguments as to why a convention would be better than another (by definition a convention is arbitrary), and even if there was, the absolute worse thing you can do is mix several conventions, because then you have 0 convention at all and never know what to expect.
At least C# tries to standardize; I've worked on several C++ codebases and I fail to see a common denominator: UpperCaseClassNames, lowerCaseClassNames, underscore_separated, tClassName, ENUMS_IN_UPPER, or not... it's rarely consistent, so the less you mix the better.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
CLtL2 has clarified the distinction between scope and extent. My take on it, in relation to lexical and special variables, is that lexical variables are “lexically scoped with indefinite extent” while special variables are “indefinitely scoped with dynamic extension.”
My question is: How are the “lexical and special variable” semantics implemented under the hood in general? By “in general,” I mean that a general idea suffices. Given the long history of Lisp, there must be numerous optimizations that have been applied to implementing these basic concepts.
To kickstart the discussion, I venture my guess below.
All start with environments. An environment is a sequence of frames, with each frame being a table that maps names to places (the value of which can be retrieved and stored); each such mapping is a binding of a name to a place. Frames are linked by the enclosing relationship; a name in an inner frame can shadow the same name in an outer frame. Also, bindings in Common Lisp default to be lexical unless declare-d/declaim-ed/proclaim-ed to be special.
There are two aspects of the semantics: name lookup and creation of a new binding.
Create a new binding. lambda expressions, let/let*, labels/flet, macrolet, and macros using them create bindings. A lexical binding is created by creating a new frame and having the current lexical environment to be the newly created frame's enclosing environment. A special binding (which must be explicitly declared) pushes a new place to the top of the stack created for the name in the current package (the stack can be located perhaps by a hash-table on names)—the stack is used for implementing the dynamic extent so that when the constructing form exits, the binding can be deconstructed by popping the stack (a question is that how to ensure so, perhaps with something like unwind-protect under the hood?).
Name lookup. Unless explicitly declared to be special, name lookup defaults to looking up in the lexical environment—through the frame link that was established during binding creation. The first matched name in the lookup process wins. For special names (which must be explicitly declared so), the lookup is served by looking at the top of the stack.
I think this question will probably get migrated to programmers.stackexchange.com, but there are some other questions on StackOverflow that provide answers to some of these questions, though none that I've found so far are exact duplicates. Have a look at:
How is Lexical Scoping implemented?
Is it possible to have hard real-time with lexical scope?
Lexical vs dynamic scoping in terms of SICP's Environment Model of Evaluation
Also, for what it's worth, you'll probably find that in compiled languages, the lexical environment “lookup” actually doesn't require much lookup, and can compiled into a constant time memory reference into the lexical environment (which is still a sort of lookup, but all the work is determined beforehand, and only the retrieval needs to happen at runtime).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Among all the various incomplete lists of features going into Scala 2.10, there are various mentions of improvements to Scaladoc. But it's unclear which ones there are, and which ones are actually going in -- e.g. one of the lists of improvements says "fixes to Scaladoc" with links to various pull requests, some of which got rejected.
Can anyone summarize what's actually changed between Scala 2.9 and 2.10 milestone 4, and maybe indicate what else is planned for 2.10 itself?
Also, are they finally going to fix the problem of not being able to link to methods? E.g. littered throughout my code I have things like this:
/**
* Reverse the encoding computed using `encode_ngram`.
*/
def decode_ngram(ngram: String): Iterable[String] = {
DistDocument.decode_ngram_for_counts_field(ngram)
}
where I want to refer to another method in the same class, but AFAIK there's simply no way to do it. IMO it should be something obvious like [[encode_ngram]] -- i.e. I definitely shouldn't need to give an absolute class (which would make everything break as soon as I pull out a class and stick it somewhere else), and I shouldn't need to give the parameter types if the method name itself is unambiguous (i.e. non-polymorphic).
Several new features, as well as many bugfixes are coming, but there's no definitive list of all the fixes that are in, yet. Of the more notable new features:
Implicitly added members will now be visible. A good example is to look at scala.Array, where methods like map which you might've assumed you had are now visible in the Scaladoc.
Automatically-generated SVG inheritance diagrams, for a bird's eye view of relationships between classes/traits/objects at the package-level and then also at the level of individual classes etc. For example, see the Scaladoc diagrams nightly at both the package-level (click "Content Hierarchy") as well as at the class-level.
Method-linking in some limited form should go into 2.10 (not in the nightly yet). (It's actually not totally trivial to implement in its complete form, due to practical stuff like overloading, as you noted.)
Improved use cases A member with a use case isn't doubly generated anymore, and they're now a bit clearer and simpler than before.
(Less-notable) Keyboard shortcuts for navigating Scaladoc have been added, they're explained here and here
For a more exhaustive list of bugfixes, it might be a good idea to write to scala-internals-- there's a good chance someone will compile a list of all major bugfixes in the past year for you there.
If I only want to check if something is impossible or not (i.e., I will not be using something like if(possible)), should I name the boolean notPossible and use if(notPossible) or should I name it possible and use if(!possible) instead?
And just to be sure, if I also have to check for whether it is possible, I would name the boolean possible and use if(possible) along with else, right?
You should probably use isPossible.
Negative names for booleans like notPossible is a very bad idea. You might end up having to write things like if (!notPossible) which makes the code difficult to read. Don't do that.
I tend to err on the side of positivity here and use possible. It means someone can't write some code later that does this...
if (!notPossible)
Which is unreadable.
I like to name booleans with consistent short-verb prefixes such as is or has, and I'd find a not prefix peculiar and tricky to mentally "parse" (so, I suspect, would many readers of the code, whether aware of feeling that way or not;-) -- so, I'd either name the variable isPossible (and use !isPossible), or just name the variable isImpossible (many adjectives have handy antonyms like this, and for a prefix has you could use a prefix lacks to make an antonym of the whole thing;-).
I generally try to name my flags so that they will read as nicely as possible where they are being used. That means try to name them so that they won't have to be negated where they are used.
I know some folks insist all names be positive, so that people don't get confused between the negations in the name and those in their head. That's probably a good policy for a boolean in a class interface. But if its local to a single source file, and I know all the calls will negate it, I'd much rather see if (impossible && ...) than if (!isPossible && ...).
Whichever is easier to read in your specifc application. Just be sure you don't end up with "if (!notPossible)".
I think it's considered preferable to avoid using negatives in variable names so that you avoid the double negative of if(!notPossible).
I recommend using isPossible. It just seems to make a lot of sense to use 'is' (or perhaps 'has') whenever you can when naming boolean variables. This is logical because you want to find out if something is possible, right?
I agree that negatively named booleans are a bad idea, but sometimes it's possible to reframe the condition in a way that's positive. For example, you might use pathIsBlocked rather than cannotProceed, or rather than isNotAbleToDie you could use isImmortal.
You should name it for exactly what is being stored in it. If you're storing whether it's possible then name it isPossible. If you're storing whether it's impossible name it isImpossible.
In either case you can use an else if you need to check for both cases.
From your description it seems more important to you to check for impossibility so I'd go with isImpossible:
if(isImpossible)
{
// ...
}
else
{
//...
}