I'm trying to come up with some clear and concise names for a Permission class that lets you check if a permission is, was, or will be, allowed/denied. I'm at a loss for what to call the future tense.
class Permission:
def can_read()
def could_read()
def will_read()?
def will_be_readable()?
I'm most partial to will_read(), but it sounds funny. will_be_readable() is clear, but its kinda long, and will_be_read() sounds misleading.
Since you are looking for a permission class, the code will be formulated as a question:
if (the_user.can_read()) ...
if (the_user.can_read_past()) ...
if (the_user.can_read_future()) ...
Apart from that I would try to maintain equal prefixes for the semantically equal function, and I would leave off the suffix for the default/most likely case. I have no real problem sacrificing grammatical correctness for a logical naming structure, even though I like to gear code towards natural language. So something like that is what I would be going for.
The will_read() sounds more like an event that is triggered before the action.
EDIT: I am aware that "can_read_past" may be percieved as "can read old stuff". Maybe Scott Evernden's suggestion is better?
was, is, and will_be is clearest to me..
or maybe readable_before, readable_now, readable_later
Yeah, English really has a problem here, with no future tense of "can"! What about switching to (say) readable_now, readable_past, readable_future? If past and future have specific meanings in your case better naming could be worked out here, I'm sure.
Since it is related to if a permission is allowed/denied, maybe there is a more descriptive word than read?
can_authorize
authorized
scheduled_to_authorize
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.
What is the best way to implement a constructor for a record? It seems like a function should be able to return a record object in the instantiation of the record in some later model higher up the tree, but I can't get that to work. For now I just use a bunch of parameters at the top of the record that populate the variables stored in the record, but it seems like that will only work in simple cases.
Can anyone shed a little light? Perhaps I shouldn't be using a record but a model. Also does anyone know how the PDE functionality is coming? The book only says that it is coming, but I have seen some other things around.
I don't seem to have the clout to add tags (which makes sense, since my "reputation" is lower than yours) so sorry about that. I thought I had actually added one at one point, but perhaps I am mistaken.
I think you need to be clear what you mean by constructor since it has a very specific meaning in Modelica. If I understand your question correctly, it sounds like what you want to do is create an instance of a record that has some fields that are specified in the constructor arguments and from those arguments a bunch of other fields in the record are computed. Is that correct?
If so, there is a mechanism to do this. You mention "the book" but it isn't clear which one you mean. If it is mine, it definitely has no mention of these so called "record constructors" because it is too old. I do not know if Peter Fritzson's book mentions them either. However, they do exist and are documented in Section 12.6 of the Modelica 3.2 specification.
As for PDEs, there has been work into this kind of thing but nothing has really been done within the design group on this topic. I would add that if you want to solve either elliptical or parabolic PDEs on regular grids, this isn't too hard even with the current language. The only real drawback is that most tools probably don't handle sparsity very efficiently. Irregular grids would also be possible, but then you get into complicated basis functions. Finally, hyperbolic PDEs are, in my opinion, quite tricky (in any environment) due to the implicit physical constraints between time and space which are difficult to express (i.e. the CFL condition).
I hope that answers your questions so far.
I can only comment on your question regarding the book of Peter Fritzson. He confirmed that he's working on an update and he hopes to get it ready 'in the course of 2011'.
Original post here:
http://openmodelica.org/index.php/forum/topic?id=50
And thanks for initiating the modelica tag, I might be useful in the near future for me too... :-)
regards,
Roel
Is it necessary to use a period for single sentence notification boxes? Even though its considered proper grammar to do so, it just looks ugly and feels too formal.
Here are two screenies for comparison (first includes period, second doesn't).
alt text http://wordofjohn.com/files/stack_alert_1.png
alt text http://wordofjohn.com/files/stack_alert_2.png
Can't go wrong with correct grammar
Good grammar shows to your customers that you took time to make a good software even where others might not took time.
This way they can expect the best out of you and your company.
If you are using a full sentence to tell the user what to do, then I think proper grammar is important, although I always stay away from exclamation points, I find them annoying.
It is more preference that anything, but I like to maintain the best grammar possible in any situation.
In both instances you capitalized the first word in the sentence so I would say go with proper grammar
but it really is a preference
I'd vote No.
These alerts are like signposts or roadsigns, they need to present a brief but important message as succinctly as possible.
My reasoning extended - I think it's subjective, and so I doubt anyone's going to have a bad user experience because of the presense or absence of a full stop (period). A question mark might be confusing if it was left out, but a full stop is kind of implicit.
If you use periods at the end of your sentences, then users will know that the string hasn't been truncated (well OK, they won't know that it hasn't been truncated, but it's a good indicator. Plus, as others have said, it shows you went to the trouble to get it right.
I can't remember - what do MS/Apple do?
Let me explain my preference with an analogy.
I used to work at a bookstore where they sold Bibles. Some of them were Cambridge calfskin leather bound deluxe editions that came in special boxes for over US$100.00 each. Some of them were mass market paperback throw-away versions for US$1.99 each. The cheap ones often had glaring grammatical and spelling errors. I don't think this was a coincidence.
Regardless of where my software is going to be used or what it is for, I try to do my best to make sure it gets put (metaphorically) on the high-quality, expensive rack. Every time. Even at the risk of sounding "too formal".
If you are using the string as a normal resource, you (or someone else in your project) could use the text in another context, which would mean you need to keep track of which resources contain a period or not.
I've always hated comments that fill half the screen with asterisks just to tell you that the function returns a string, I never read those comments.
However, I do read comments that describe why something is done and how it's done (usually the single line comments in the code); those come in really handy when trying to understand someone else's code.
But when it comes to writing comments, I don't write that, rather, I use comments only when writing algorithms in programming contests, I'd think of how the algorithm will do what it does then I'd write each one in a comment, then write the code that corresponds to that comment.
An example would be:
//loop though all the names from n to j - 1
Other than that I can't imagine why anyone would waste valuable time writing comments when he could be writing code.
Am I right or wrong? Am I missing something? What other good use cases of comments am I not aware of?
Comments should express why you are doing something not what you are doing
It's an old adage, but a good metric to use is:
Comment why you're doing something, not how you're doing it.
Saying "loop through all the names from n to j-1" should be immediately clear to even a novice programmer from the code alone. Giving the reason why you're doing that can help with readability.
If you use something like Doxygen, you can fully document your return types, arguments, etc. and generate a nice "source code manual." I often do this for clients so that the team that inherits my code isn't entirely lost (or forced to review every header).
Documentation blocks are often overdone, especially is strongly typed languages. It makes a lot more sense to be verbose with something like Python or PHP than C++ or Java. That said, it's still nice to do for methods & members that aren't self explanatory (not named update, for instance).
I've been saved many hours of thinking, simply by commenting what I'd want to tell myself if I were reading my code for the first time. More narrative and less observation. Comments should not only help others, but yourself as well... especially if you haven't touched it in five years. I have some ten year old Perl that I wrote and I still don't know what it does anymore.
Something very dirty, that I've done in PHP & Python, is use reflection to retrieve comment blocks and label elements in the user interface. It's a use case, albeit nasty.
If using a bug tracker, I'll also drop the bug ID near my changes, so that I have a reference back to the tracker. This is in addition to a brief description of the change (inline change logs).
I also violate the "only comment why not what" rule when I'm doing something that my colleagues rarely see... or when subtlety is important. For instance:
for (int i = 50; i--; ) cout << i; // looping from 49..0 in reverse
for (int i = 50; --i; ) cout << i; // looping from 49..1 in reverse
I use comments in the following situations:
High-level API documentation comments, i.e. what is this class or function for?
Commenting the "why".
A short, high-level summary of what a much longer block of code does. The key word here is summary. If someone wants more detail, the code should be clear enough that they can get it from the code. The point here is to make it easy for someone browsing the code to figure out where some piece of logic is without having to wade through the details of how it's performed. Ideally these cases should be factored out into separate functions instead, but sometimes it's just not do-able because the function would have 15 parameters and/or not be nameable.
Pointing out subtleties that are visible from reading the code if you're really paying attention, but don't stand out as much as they should given their importance.
When I have a good reason why I need to do something in a hackish way (performance, etc.) and can't write the code more clearly instead of using a comment.
Comment everything that you think is not straightforward and you won't be able to understand the next time you see your code.
It's not a bad idea to record what you think your code should be achieving (especially if the code is non-intuitive, if you want to keep comments down to a minimum) so that someone reading it a later date, has an easier time when debugging/bugfixing. Although one of the most frustrating things to encounter in reading someone else's code is cases where the code has been updated, but not the comments....
I've always hated comments that fill half the screen with asterisks just to tell you that the function returns a string, I never read those comments.
Some comments in that vein, not usually with formatting that extreme, actually exist to help tools like JavaDoc and Doxygen generate documentation for your code. This, I think, is a good form of comment, because it has both a human- and machine-readable format for documentation (so the machine can translate it to other, more useful formats like HTML), puts the documentation close to the code that it documents (so that if the code changes, the documentation is more likely to be updated to reflect these changes), and generally gives a good (and immediate) explanation to someone new to a large codebase of why a particular function exists.
Otherwise, I agree with everything else that's been stated. Comment why, and only comment when it's not obvious. Other than Doxygen comments, my code generally has very few comments.
Another type of comment that is generally useless is:
// Commented out by Lumpy Cheetosian on 1/17/2009
...uh, OK, the source control system would have told me that. What it won't tell me is WHY Lumpy commented out this seemingly necessary piece of code. Since Lumpy is located in Elbonia, I won't be able to find out until Monday when they all return from the Snerkrumph holiday festival.
Consider your audience, and keep the noise level down. If your comments include too much irrelevant crap, developers will just ignore them in practice.
BTW: Javadoc (or Doxygen, or equiv.) is a Good Thing(tm), IMHO.
I also use comments to document where a specific requirement came from. That way the developer later can look at the requirement that caused the code to be like it was and, if the new requirement conflicts with the other requirment get that resolved before breaking an existing process. Where I work requirments can often come from different groups of people who may not be aware of other requirements then system must meet. We also get frequently asked why we are doing a certain thing a certain way for a particular client and it helps to be able to research to know what requests in our tracking system caused the code to be the way it is. This can also be done on saving the code in the source contol system, but I consider those notes to be comments as well.
Reminds me of
Real programmers don't write documentation
I wrote this comment a while ago, and it's saved me hours since:
// NOTE: the close-bracket above is NOT the class Items.
// There are multiple classes in this file.
// I've already wasted lots of time wondering,
// "why does this new method I added at the end of the class not exist?".
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