In Modula-2 and Oberon each module and procedure declaration must end with the name of the module or procedure. It is not needed in Pascal. I have never really understood the motivation for this. Can someone enlighten me?
After reading some (I am not an expert) I would wager this is just a syntax demand of the function for better readability.
I'll go one step further, and say in large, old, badly written procedures/function in other languages, this is sometimes done without the language requiring it. I've often seen:
int veryLongC++Function() {
...
...
... 3000 code lines
} //veryLongC++Function
So a reader jumping near the end knows what in the mess they are looking at. August mentions in the comment this is much less robust when not enforced by the compiler - in case of a name change.
Another important aspect is nested procedures - here the explicit ending makes things much more readable - checkout chapter 7 for an example - a nested procedure is declared between a declaration and before the BEGIN. The syntax makes this looks much better (in my opinion).
So long story short - I think the main benefit is readability.
It's possible you get something like this:
MODULE A;
...
PROCEDURE B;
...
PROCEDURE C;
...
BEGIN (* C *)
...
END C;
BEGIN (* B *)
...
END B;
BEGIN (* A *)
...
END A.
In that case, for readability you have three bodies (and more if you have defined nested procedures and functions) at the end of your code. In order to see which one is the one ending in the END clause, it's better if the compiler can check that you ar closing things correctly (as you see, I even put it ---as a comment, but would be nice if the compiler accepted it as a valid identifier and checked just to be sure things match correctly--- at the start BEGIN body clause)
Related
I am reading someone else sql and his code was like this
There is view called user_v with column path as Array
select * from user_v where 'USER_TYPE'=path[2]
can't i use
path[2] = 'USER_TYPE'
This is a precaution taken by some programmers in languages where assignment and comparison can be easily confused, such as C or PHP, where the following statement looks innocent:
if ( $foo = 1 )
but it is actually assigning 1 to $foo, and the if will always evaluate to true (in PHP, at least, where 1 is true). What was meant was if ( $foo == 1 ).
If you reverse the arguments, the error becomes obvious sooner:
if ( 1 = $foo ) # SYNTAX ERROR
if ( 1 == $foo ) # Desired behaviour
This is sometimes known as "yoda coding", and is in the coding standards of Wordpress, for example.
See also: Why put the constant before the variable in a comparison?
In SQL, there is less chance of such a muddle, since although = can mean either assignment or comparison, there are rarely situations where a typo would select the wrong meaning.
However, if the coding standards for every other language used by a project mandate it, it would make sense to reinforce the habit by also using it in SQL, since I can't think of a specific reason not to write it that way.
There is no difference at all.
It's psychology.
You would want to read someone else's code out laud and say:
Where my column equals 2.
When you read:
Where 2 equals my column
you have to stop for a while, return, explain it to yourself.
We maintain all of these rules that seem rubish at first glance just to make other people lives easier.
I didn't touch Prolog since high-school, and even though I've tried to find the info, it didn't help. Below is the example that has to illustrate my problem:
%% everybody():- [dana, cody, bess, abby].
%% Everybody = [dana, cody, bess, abby].
likes(dana, cody).
hates(bess, dana).
hates(cody, abby).
hates(X, Y):- \+ likes(X, Y).
likes_somebody(_, []):- fail.
likes_somebody(X, [girl | others]):-
likes(X, girl) ; likes_somebody(X, others).
likes_everybody(_, []):- true.
likes_everybody(X, [girl | others]):-
likes(X, girl) , likes_everybody(X, others).
maplist(likes_somebody, [dana, cody, bess, abby], [dana, cody, bess, abby]).
How do I declare everybody to just be the list of girls? The commented lines are those which I've tried, but I've got bizarre error messages back.
This is the tutorial I followed more or less so far. I'm using GProlog, if it makes any difference. Sorry for such a basic question. GProlog's manual doesn't deal with language syntax, but I've certainly looked there. As an aside, I would be grateful for information on where to look for language documentation (as opposed to implementation documentation).
Every variable in Prolog must begin with an uppercase letter. So for starters, you want Everybody, not everybody.
Second problem, variables in Prolog are not assignables. So probably what you want to do is make a fact and use that instead:
everybody([dana, cody, bess, abby]).
Your bottom line of code is actually a fact definition and will attempt to overwrite maplist/3. What you probably want to do is put everything above that line into a file (say, called likes.pl) and then consult it ([likes].). Then you can run a query like this:
?- everybody(Everybody), maplist(likes_somebody, Everybody, Everybody).
This won't work, because likes_somebody/2 processes a list in the second argument. The predicate you have for likes_somebody/2 could be written:
likes_somebody(_, []).
but still won't mean much. It simply unifies anything with the empty list:
?- likes_somebody(chicken_tacos, []).
true.
You really need a predicate to tell you if someone is a girl, like this:
girl(dana).
girl(cody).
girl(bess).
girl(abby).
Then you could do what I think you're trying to do, which is something closer to this:
likes_somebody(X) :- girl(X).
Then the maplist construction would work like this:
everybody(Everybody), maplist(likes_somebody, Everybody).
Which would simply return true. You could simplify and eliminate everybody/1 by instead using findall(Girl, girl(X), Everybody) but it's getting weird.
You're trying to do list processing with likes_everybody/2, but it's broken because girl is literally girl, not a variable, and others is literally others, not a list of some kind that could be the tail of another list.
I think you still have some old ideas you need to cleanse. Read some more, write some more, and your code will start to make a lot more sense.
I'm trying to simplify my code by using #define statements. This is because it contains a lot of repetitive "chunks" of code that cannot be repeated using the obvious alternative, functions, because in these chunks, variables need to be declared like you'd do in a #define statement, e.g. #define dostuff(name) int name##Variable;.
Code
#define createBody(name,type,xpos,ypos,userData,width,height) b2BodyDef name##BodyDef;\
name##BodyDef.type = type==#"dynamic"?b2_dynamicBody:b2_staticBody;\
name##BodyDef.position.Set(xpos,ypos);\
name##BodyDef.userData = userData;\
name=world->CreateBody(&name##BodyDef);\
b2PolygonShape name##shape;\
name##shape.SetAsBox(width/ptm_ratio/2,height/ptm_ratio/2);
... and applying that in the following:
createBody(block, #"dynamic", winSize.width*5/6/ptm_ratio, winSize.height*1/6/ptm_ratio, ((__bridge void*)blockspr), blockspr.contentSize.width, blockspr.contentSize.height)
// error appears there: ^
Now my point is that everything's working great, no errors, except a single one that's freaking me out:
Expected unqualified-id
which points at the first bracket in ((__bridge ..., as indicated. (That argument gets passed via the userData argument to createBody.)
I know this code is nowhere near simple, but since everything else is working, I believe that an answer must exist.
This is my first question on SO, so if there's anything unclear or insufficient, please let me know!
I'm trying to simplify my code by using #define statements.
This sounds an alarm in my mind.
Break this down into functions. You said you can't. I say you can.
Notice that your macro here:
createBody(name,type,xpos,ypos,userData,width,height);
It has exactly the same syntax as a C function. So you've already created a function, you only declared it as a macro. There's no reason why you couldn't rewrite it as a function (C or Objective-C doesn't matter). You do not need to give each body its own name, instead you could store them in a dictionary (careful though because Box2D takes ownership of the bodies).
Do you think x, y, z are good variable names? How will you explain a new programmer to write readable code?
Readable code means some combination of comments and variable and function naming that allows me to read the code once and understand it. If I have to read it more than once, or spend my time working through complicated loops or functions, there's room for improvement.
Good summary descriptions at the top of files and classes are useful to give the reader context and background information.
Clear names are important. Verbose names make it much easier to write readable code with far fewer comments.
Writing readable code is a skill that takes some time to learn. I personally like overly verbose names because they create self documenting code.
As already stated x, y, and z are good variables for 3D coordinates but probably bad for anything else...
If someone does not believe that names are important, just use a code obfuscator on some code then ask them to debug it :-).
(BTW that's the only situation where a code obfuscator can be useful IMHO)
There seems to be slightly different conventions per progamming language; however, the consensus these days is to...
use pascal case
make the name meaningful
end with a noun
Here is a decent recap of what Microsoft publishes as standard naming conventions for .NET
The inventor of python has published a style guide which includes naming conventions.
There was a time when Microsoft VC++ developers (myself included) actually rallied around what was known as Hungarian Notation
Certainly there are multiple schools of thought on this, but I would only use these for counters, and advise far more descriptive names for any other variables.
x, y and z can be perfectly good variable names. For example you might be writing code that refers to them in reference to a 3D cartesian coordinate system. These names are often used for the three axes in such a system and as such they would be well suited.
I would give them some maintenance work on some code with variables called x, y, z and let them realise for themselves that readability is vital...
95% of code viewing is not by the author, but by the customer that everyone forgets about - the next programmer. You owe it to her to make her life easy.
Good variable names describe exactly what they are without being overly complex. I always use descriptive names, even in loops (for instance, index instead of i). It helps keep track of what's going on, especially when I'm working on rewriting a particularly complex piece of code.
Well give them a chunk of bad code and ask them to debug it.
Take the following code (simple example)
<?php $a = fopen('/path/to/file.ext', 'w');$b = "NEW LINE\n";fwrite($a, $b);fclose($a);?>
The bug is: File only ever contains 1 line when it should be a log
Problem: 'w' in fopen should be 'a'
This obviously is a super easy example, if you want to give them a bigger more complicated example give them the WMD source and ask them to give you readable code in 2 hours, it will get your point across.
As long as x, y and z are (3D) Cartesian co-ordinates, then they're great names.
In a similar vein, i, j and k would be OK for loop variables.
In all cases, the variable names should relate to the data
x,y and z are acceptable variable names if they represent 3d coordinates, or if they're used for iterating over 2 or 3 dimensional arrays.
This code is fine as far as I'm concerned:
for(int x = 0; x < xsize ; x++)
{
for(int y = 0; y < ysize ; y++)
{
for(int z = 0; z < zsize ; z++)
{
DoSomething(data[x][y][z]);
...
This one is a short answer, but it works very well for me:
If it would need a code comment to describe it, then rethink the variable name.
So if it's obvious, why "x" was choosen, then they are good names. E.g. "i" as variable name in a loop is (often) pretty obvious.
An ideal variable name is both short (to make the code more compact) and descriptive (to help understanding the code).
Opinions differ on which of the two is more important. Personally, I'd say it depends on the scope of the variable. A variable used only inside a 3 line loop can get away with being single letter. A class field in a 500 line class better be pretty damn descriptive. The Spartan Programming philosophy says that as far as possible, all units of code should be small enough that variable names can be very short.
Readable code and good naming conventions are not the same thing!
A good name for a variable is one that allows you to understand (or reasonably guess) the purpose and type of the variable WITHOUT seeing the context in which it is used. Thus, "x" "y" and "z" say coordinates because that is a reasonable guess. Conversely, a bad name is one that leads you to a wrong likely guess. For example, if "x" "y" and "z" represent people.
A good name for a function is one that conveys everything you would need to know about it without having to consult its documentation. That is not always possible.
Readable code is first of all code whose structured could be understood even if you obfuscated all variable and function names. If you do that and can't figure out the control structure easily, you're screwed.
Once you have readable code and good naming, then maybe you'll have truly readable code.
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.