As every new programer starting in Go 1st think you see is, strict code format.
Means:
//Valid
func foo(){
}
//Invalid
func foo()
{
}
Same goes for if-else that else should be in same line where if ends, like:
//Valid
if{
}else{
}
//Invalid
if{
}
else{
}
we get below error:
syntax error: unexpected else, expecting }
I have checked the spec spec, but not able to find why.
The only explanation I'am getting is its mandatory.
Can anyone explain us why this is mandated does this have any reason? if any.
UPDATE
I think i have mention this already that "I know lang say so", Question is WHY?
Why to go this length to make it compile time error, what problems it was posing if we don't do this?
The language was designed as such and the reason is outlined in the FAQ.
https://golang.org/doc/faq
Why are there braces but no semicolons? And why can't I put the opening brace on the next line?
o uses brace brackets for statement
grouping, a syntax familiar to programmers who have worked with any
language in the C family. Semicolons, however, are for parsers, not
for people, and we wanted to eliminate them as much as possible. To
achieve this goal, Go borrows a trick from BCPL: the semicolons that
separate statements are in the formal grammar but are injected
automatically, without lookahead, by the lexer at the end of any line
that could be the end of a statement. This works very well in practice
but has the effect that it forces a brace style. For instance, the
opening brace of a function cannot appear on a line by itself.
Some have argued that the lexer should do lookahead to permit the
brace to live on the next line. We disagree. Since Go code is meant to
be formatted automatically by gofmt, some style must be chosen. That
style may differ from what you've used in C or Java, but Go is a
different language and gofmt's style is as good as any other. More
important—much more important—the advantages of a single,
programmatically mandated format for all Go programs greatly outweigh
any perceived disadvantages of the particular style. Note too that
Go's style means that an interactive implementation of Go can use the
standard syntax one line at a time without special rules.
Go inserts a ; at the end of lines ending in certain tokens including }.
Since if {...} else {...} is a single statement, you can't put a semicolon in the middle of it after the first closing brances i.e. }, hence the requirement to put } else { on one line is mandatory.
I hope it answers your question.
Related
I was looking at this link for clarification on the Linux Kernel Coding Style (https://www.kernel.org/doc/html/v4.15/process/coding-style.html#placing-braces-and-spaces)
However I do not see any explanation on how to format nested if-statements. Here is the chunk of code that I am questioning:
if (cond1) {
if (cond2) {
1 line of code...
}
} else {
1 line of code again...
}
Does the nested if statement need the curly braces, even though it only has 1 line of code? I know that the else statement does need the curly braces, since that is what the docs specify. I am trying to avoid any styling issues that result in my commit getting rejected. Thank you.
As #Tsyvarev mentioned - there is no specific conventions for nested if-statements.
Regarding single-line if-statements - you don't have to. Keep in mind though that one of the main goals of conventions is to maintain code readability. In the end, your code should be readable. If a curly braces makes your code more readable, even if it is only one line - then use curly braces.
I am working through some code other people have written and found a piece of Fortran syntax that I haven't seen yet and don't exactly understand nor can seem to find anything on the web about (probably because I don't know what it's called).
The code looks like this:
bisection_or_ordering:if(ordering /= 'bisection') then
...
do stuff
...
end if bisection_or_ordering
bisection_or_ordering is not a variable and not declared anywhere in the code.
What does this do? What is it for? And what is it called?
The part before the colon is a construct name.
Executable constructs with blocks - if, block, associate, critical, select case, select type and of course do - may optionally have these construct names.
They are useful both for identification (for clarity with nested or long constructs) but also for control under the exit statement (except to escape critical or do concurrent blocks).
The construct name may appear on the closing statement of the block, as in the question's example, but it is optional and must match if present.
In JavaScript,
f = function(x) {
return x + 1;
}
(5)
seems at a glance as though it should assign f the successor function, but actually assigns the value 6, because the lambda expression followed by parentheses is interpreted by the parser as a postfix expression, specifically a function call. Fortunately this is easy to fix:
f = function(x) {
return x + 1;
};
(5)
behaves as expected.
If Python allowed a block in a lambda expression, there would be a similar problem:
f = lambda(x):
return x + 1
(5)
but this time we can't solve it the same way because there are no semicolons. In practice Python avoids the problem by not allowing multiline lambda expressions, but I'm working on a language with indentation-based syntax where I do want multiline lambda and other expressions, so I'm trying to figure out how to avoid having a block parse as the start of a postfix expression. Thus far I'm thinking maybe each level of the recursive descent parser should have a parameter along the lines of 'we have already eaten a block in this statement so don't do postfix'.
Are there any existing languages that encounter this problem, and how do they solve it if so?
Python has semicolons. This is perfectly valid (though ugly and not recommended) Python code: f = lambda(x): x + 1; (5).
There are many other problems with multi-line lambdas in otherwise standard Python syntax though. It is completely incompatible with how Python handles indentation (whitespace in general, actually) inside expressions - it doesn't, and that's the complete opposite of what you want. You should read the numerous python-ideas thread about multi-line lambdas. It's somewhere between very hard to impossible.
If you want arbitrarily complex compound statements inside lambdas you can't use the existing rules for multi-line expressions even if you made all statements expressions. You'd have to change the indentation handling (see the language reference for how it works right now) so that expressions can also contain blocks. This is hard to do without breaking perfectly fine Python code, and will certainly result in a language many Python programmers will consider worse in several regards: Harder to understand, more complex to implement, permits some stupid errors, etc.
Most languages don't solve this exact problem at all. Most candidates (Scala, Ruby, Lisps, and variants of these three) have explicit end-of-block tokens. I know of two languages that have the same problem, one of which (Haskell) has been mentioned by another answer. Coffeescript also uses indentation without end-of-block tokens. It parses the transliteration of your example correctly. However, I could not find any specification of how or why it does this (and I won't dig through the parser source code). Both differ significantly from Python in syntax as well as design philosophy, so their solution is of little (if any) use for Python.
In Haskell, there is an implicit semicolon whenever you start a line with the same indentation as a previous one, assuming the parser is in a layout-sensitive mode.
More specifically, after a token is encountered that signals the start of a (layout-sensitive) block, the indentation level of the first token of the first block item is remembered. Each line that is indented more continues the current block item; each line that is indented the same starts a new block item, and the first line that is indented less implies the closure of the block.
How your last example would be treated depends on whether the f = is a block item in some block or not. If it is, then there will be an implicit semicolon between the lambda expression and the (5), since the latter is indented the same as the former. If it is not, then the (5) will be treated as continuing whatever block item the f = is a part of, making it an argument to the lamda function.
The details are a bit messier than this; look at the Haskell 2010 report.
I'm trying to curb some of the bad habits of a self-proclaimed "senior programmer." He insists on writing If blocks like this:
if (expression) {}
else {
statements
}
Or as he usually writes it in classic ASP VBScript:
If expression Then
Else
statements
End If
The expression could be something as easily negated as:
if (x == 0) {}
else {
statements
}
Other than clarity of coding style, what other reasons can I provide for my opinion that the following is preferred?
if (x != 0) {
statements
}
Or even the more general case (again in VBScript):
If Not expression Then
statements
End If
Reasons that come to my mind for supporting your opinion (which I agree with BTW) are:
Easier to read (which implies easier to understand)
Easier to maintain (because of point #1)
Consistent with 'established' coding styles in most major programming languages
I have NEVER come across the coding-style/form that your co-worker insists on using.
I've tried it both ways. McConnell in Code Complete says one should always include both the then and the else to demonstrate that one has thought about both conditions, even if the operation is nothing (NOP). It looks like your friend is doing this.
I've found this practice to add no value in the field because unit testing handles this or it is unnecessary. YMMV, of course.
If you really want to burn his bacon, calculate how much time he's spending writing the empty statements, multiply by 1.5 (for testing) and then multiply that number by his hourly rate. Send him a bill for the amount.
As an aside, I'd move the close curly bracket to the else line:
if (expression) {
} else {
statements
}
The reason being that it is tempting to (or easy to accidentally) add some statement outside the block.
For this reason, I abhor single-line (bare) statements, of the form
if (expression)
statement
Because it can get fugly (and buggy) really fast
if (expression)
statement1
statement2
statement2 will always run, even though it might look like it should be subject to expression. Getting in the habit of always using brackets will kill this stumbling point dead.
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 1 year ago.
Improve this question
Ever since I first wrote
if ($a = 5) {
# do something with $a, e.g.
print "$a";
}
and went through the normal puzzling session of
why is the result always true
why is $a always 5
until I realized, I'd assigned 5 to $a, instead of performing a comparison.
So I decided to write that kind of condition above as
if (5 == $a)
in other words:
always place the constant value to the left side of the comparison operator, resulting in a compilation error, should you forget to add the second "=" sign.
I tend to call this defensive coding and tend to believe it's a cousin to defensive-programming, not on the algorithmic scale, but keyword by keyword.
What defensive coding practices have you developed?
One Week Later:
A big "thank you" to all who answered or might add another answer in the future.
Unfortunately (or rather fortunately!) there is no single correct answer. For that my question was to broad, asking more for opinions or learnings of experience, rather than facts.
Always use braces:
if(boolean)
oneliner();
nextLineOfCode();
is not the same as:
if(boolean)
{
oneliner();
}
nextLineOfCode();
If oneliner() is a #defined function, and it isn't defined then your next line of code suddenly becomes subject to the if(). Same thing applies to for loops etc. With braces then the next piece of code never unintentionally becomes conditional on the if/for etc.
The top 3 defensive coding practices I employ are
unit testing
unit testing
unit testing
There is no better defense for the quality of your code than a good unit test to back you up.
This is a simple and obvious one, but I NEVER EVER NEVER repeat the same string constant twice in my code, cause I KNOW that if I do I will be spelling one of them wrong :) Use constants, people!
Always put curly braces after an if/for/while ... even if there's only one single statement after. BTW D. Crockford thinks it's better too: Required blocks
When comparing a string with a constant, write
if ("blah".equals(value)){}
instead of
if (value.equals("blah")){}
to prevent a NullPointerException. But this is the only time I use the suggested coding-style (cause "if (a = 1)..." is not possible in Java).
One of the things I always try to remember when I am in the Javascript world is to always start the return value of a function on the same line as the return key word.
function one(){
return {
result:"result"
};
}
function two(){
return
{
result:"result"
};
}
These 2 functions will not return the same value. The first function will return an Object with a property results set to "result". The second function will return undefined. It's a really simple mistake and it happens because of Javascript's over-zealous Semi-Colon Insertion strategy. Semi-colons are semi-optional in Javascript and because of this the Javascript engine will add semi-coons where it thinks it's should be. Because return is actually a valid statement a semi-colon will be inserted after the return statement and the rest of the function will essentially be ignored.
From my blog:
Think positive and return early plus avoid deep nesting. Instead of
if (value != null) {
... do something with value ...
}
return
write
if (value == null) {
return
}
... do something with value ...
Avoid "string constants" (i.e. the same text in quotes in more than one place). Always define a real constant (with a name and an optional comment what it means) and use that.
Personally, I dislike this defensive style, it makes the code hard ro read.
VC compiler warning level 4 will spot this (possible) error.
"warning C4706: assignment within conditional expression"
You can enable just this specific compiler warning, at any level:
#pragma warning(3,4706)
Always initialize variables
Use const wherever I can (without using mutable)
Avoid bare dynamic allocation of memory or other resources
Always use curly braces
Code use-cases and tests for any class before coding implementation
Turn on as many useful warnings as I can (-Wall -Wextra -ansi -pedantic -Werror at a minimum)
Use the simplest tool that solves the problem (in my current environment, that's bash -> grep -> awk -> Python -> C++).
I stopped using languages where you can do
if a = 5: print a
This has saved me tons of headaches =).
On a more serious note... I now always write the curly braces right after I write my ifs and for loops, and then fill them in afterwards. This makes sure my brackets are always aligned.
Returning a copy of a mutable object, i.e. a copy of an array, not the mutable object itself.
Couple things:
Yes, the 1-line blocks. Use the braces... heck, most good IDE's will make em for you.
Comment your code after you write it, or re-read your comments if you did it ahead of time. Make sure your code still does what the comments say.
Unit testing is a great fallback to re-reading your code.
Always log an exception... or, NEVER catch an exception without saying so, at least in debug.
Avoid unnecessary test.
Example
if(bool == true)
Pointer checks if(pointer)
EDIT:
if(pointer) is not readable so nowadays I prefer if(NULL != pointer)
Installed Resharper ;)
Then I don't need to write "5 == a" to get warned if I did something wrong :)