Ruby - Difference between if and if then statements [duplicate] - ruby

This question already has answers here:
What is the difference between "if" statements with "then" at the end?
(5 answers)
Closed 8 years ago.
In Ruby, I know that control flow statements typically follow the following pattern.
If statement
do something
else
do something else
end
From my experiences that was the only pattern I noticed. However, when looking at code on a website, I saw something new that looked similar (if-then). I've never seen that before and would appreciate any explanations.
if statement then
do something
else
do something else
end
I'd like to know what the difference between those code blocks is. They seem to do the same thing.
Edit: I would like to clarify, I'm talking about an if then line followed by a block, not if then on one line. Please keep that in mind

The "then" syntax is used when you want to use the "if" expression on one line. In this case there needs to be a separator to ensure the line is understood by the interpreter.
See here Ruby If Syntax

Related

What is the traceback/local jumpback error in irb repl when writing multiline code?

I am a newbie, forgive if this is an obvious question but does anyone know why my irb repl isn't able to do multilines? I have tried lots of different if statements (copied from course notes that I am doing - but not copied and pasted just typed) and I get this traceback message every time.
Will be grateful for advice!
I've just read in the notes that this is due to doing a return that isn't in a method. It might become clearer later on.
Also, just copying this answer that was added as a comment so other people see it. Removing the 'return' works:
"While there are reasons to use the return keyword in ruby, if you are just learning start out by never typing this word. Ruby will always return the last statement executed, so just rely on this fact for now and structure your programming around it."

GoLang: Semantic Meaning of a Property Wrapped in Parenthesis? [duplicate]

This question already has answers here:
What is this "err.(*exec.ExitError)" thing in Go code? [duplicate]
(2 answers)
What is the meaning of "dot parenthesis" syntax? [duplicate]
(1 answer)
Closed 5 years ago.
Go Newb here -- I've encountered the following bit of Go code that I didn't write
if tc, ok := tng.(ThingClasser); ok {
//... do some stuff ...
}
I won't understand the semantics of tng.(ThingClasser).
In some ways this looks like a method call -- i.e. there are two variables (ec, ok) sitting there ready to accept multiple return values.
However, tng.(ThingClasser) itself looks like its a property access, not a method call.
However however, the parens around ThingClasser are a wrinkle I've never seen before. Also, if it matters, the ThingClasser symbol is defined elsewhere in this project as an interface, so I think maybe this is some syntactic sugar around an does this implement an interface -- but then the two return values confused me.
Googling hasn't turned up anything concrete, but this is one of those hard things to google for.
Does anyone here know what this call/syntax is in GoLang, and possible point me at the relevant manual pages so I can RTFM?
It's a type assertion. The returned values are 1) the object, converted to the given type; and 2) a boolean indicating if the conversion was successful. ThingClasser is the type being converted to. Documentation can be found here: https://golang.org/ref/spec#Type_assertions

Uncommon Ruby syntax <<ABC – what does it accomplish? [duplicate]

This question already has answers here:
What does <<-CONSTANT do?
(3 answers)
Closed 6 years ago.
Just found this piece of code in a Google Ruby API client on Github.
NOT_FOUND_ERROR = <<END
Could not load the default credentials. Browse to
https://developers.google.com/accounts/docs/application-default-credentials
for more information
END
I never saw it and tested it in the console:
>> NOT_FOUND_ERROR = <<END
blabla
END
=> "blabla\n"
So basically it is a weird way to create a string? What's the motivation for using this syntax rather than NOT_FOUND_ERROR = "blabla\n" ?
EDIT: As this question was marked with "possible duplicate" I want to explain why it is not just a dup. The question that is a possible duplicate simply asks what a certain ruby script does. This Ruby script also includes the <<ABC syntax and this obviously is the core of the question, but it is not really helpful because it is hard to find. Besides that, I am going further and ask for the motivation to use this notation over creating a normal string.
It is HEREDOC. You can read more about it here(wiki) and here(Ruby instances). Usually heredocs used for more readability of multiline text.

Is there anyway to analyze a particular code (particularly if and for loops) in bash (or another language)? [duplicate]

This question already has answers here:
Pretty-print for shell script
(4 answers)
Closed 7 years ago.
Talking about good coding practices. My code is getting bigger and bigger and I want to check if all my "if", and "for" loops are properly written.
I think the proper word for that is indentation (thanks #tgo).
So I have this:
if(cond1 = cond2)
if(cond3=cond4)
bla
fi
fi
but I want the following:
if(cond1 = cond2)
if(cond3=cond4)
bla
fi
fi
But for instance using Sublimetext I cannot see it like this. So repeating the question, is there any tool, software or something that can help me with this?
update: Sublime text has an option for this. (Edit-> line-> Indent) I couldn't add this to the answer.
I use vim for all my code editting (and I write a lot of bash scripts) and it has smart indenting that defaults to normal, ok stuff for all the languages I use. If you have smart indenting turned on and copy and paste code from your first block into vim (properly set up with filetype=sh), it'll turn out like your second block.

Should 'if' statement always have an 'else' clause? [closed]

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 9 years ago.
Improve this question
This may be a religious argument, but it has been debated ad-nauseum here at my work whether all IF statements should include an ELSE clause - even if the ELSE clause only contains a comment stating that it was 'intentionally left blank'.
I have heard arguments for both sides:
The 'For' camp - ensures that the code has actually addressed whether the condition requires an ELSE clause
The 'Against' camp - code is harder to read, adds too much noise
I am interested in any other points of view as I have to resolve this debate with an answer that would satisfy both parties.
Seems like useless typing to me... and a possible cause for confusion. If you don't need it, don't put it!
No. If you don't need to run any code on the else side, you don't need an else clause.
It is clear by the responses here that no one feels an unused else is needed. I have never heard nor read of such a thing. The more important issue before you is dealing with co-workers/developers who somehow believe adamantly that this is how If Then is to be used.
It sounds like you are not the senior person in this scenario so you cannot simply decree it to be so. I suggest asking the "empty else" parties to show where such a process is suggested in a book (blogs don't count) about development. Better yet, in 3 books about development. I have read my share of programming books across programming languages since 1982 and I have never seen such a suggestion.
This way you are not telling them that they are wrong which they could take personally. Instead you are willing to accept such a position but would like to see some documentation. The onus is on them to find the proof. Either they find it or they are left to argue that every programming book ever written is wrong while only they are right.
Good luck.
The golden rule: put it in if it makes your code clearer and easier to understand, and leave it out otherwise. An experienced programmer will be able to make these judgements on a case-by-case basis.
Are you talking about Algol-derived languages?
In Lisp, I'd say yes: every IF should have an else-clause. Otherwise, you should be using WHEN.
As you say, this may be a question of style, but I would not dream of putting in empty else-blocks in my code just because "every if-block should have one". In my opinion, it adds nothing else than some more characters in the code and one more point (of very little value) to spend time on during code reviews.
Requiring an else stinks. Use it when needed. All programmers understand the construct and the implication of a missing else. It's like a pointless comment that echoes the code. It's plain daft IMO.
I tend to use "early if" statements as means of reducing the level of nested braces (or indentation in Python) like so:
if (inParam == null) {
return;
}
if (inParam.Value < 0) {
throw new ArgumentException(...,...);
}
// Else ... from here on my if statements are simpler since I got here.
Of course, .Net 4.0 now has code contracts, which is great! But, most languages do not have that just yet, so "early ifs" (for the lack of better term) are great precisely because they eliminate a number of else clauses and nested ifs. I do not think it is beneficial to have an else clause in high-level languages ... heck, even in assembly! The idea is: if you checked and did not jump, then the condition was false and we can carry on. Makes logical sense to me ...
EDIT: Check out this article as well to see why else clauses are not of much help:
http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html
"ensures that the codes has actually
addressed whether the condition
requires an ELSE clause"
This is no more true than requiring a catch clause in every method ensures that all possible exceptions has been properly handled.
No. Guard conditions are a great example. You could nest the rest of the method logic in else clauses but it could get ugly really quickly.
Having an "else" with just an empty line of a code comment can usually mean the developer thought-through the condition and has a better idea of what execution path is actually taken at a given time. All recent compilers will remove the "else" and the comment, so you are not slowing software execution.
Unless I am reading the other responses incorrectly, it looks like most folks are objecting to the time it takes to declare their thoughts in the code and would rather just do it.
SQL Server 2000, 2005 at least.
IF 1 = 1
BEGIN
PRINT 'doing something productive'
END
ELSE
BEGIN
--Just sitting here
END
Msg 102, Level 15, State 1, Line 8
Incorrect syntax near 'END'.
You have to have a meaningful statement, which means a dummy assign or return data to client. I suppose I could use WAITFOR DELAY...
Haskell's if is always ternary. So else is mandatory.
if (thereIsSomeThingToDoInTheElse)
{
putAnElseClause();
}
else
{
// intentionally left blank
}
If your code is complex enough that this becomes an issue, you should probably be rethinking your approach to the problem. Break what you're doing down into smaller simpler functions where it should be unbelievably obvious what the if statements are doing.
If you can't break it down into smaller functions, or you find yourself nesting more than one if statement inside another, Using if statements for your conditional logic are probably not a good fit. Consider switches, lookup tables (if the only difference between your conditions is the value of some constant), or decision tables instead.
If you've already done all this, then you are quibbling over something so unbelievably trivial it's hardly worth your time to argue it.
One of the few possible situations where this might be a good idea is where you have several nested if statements, but fewer else clauses. The language will specify which if the else matches, but this may not always be clear to the reader. Of course, where you put content in curly brackets, nesting will be obvious, so there's no ambiguity. This make this a bit of an artificial case, but still possibly worth mentioning. Also, if your code is this complicated, there's probably a clearer way of writing it.
There are situations where using an optional syntax element when not required can improve readability or prevent future errors. A typical case are the brackets around one-sentence conditionals:
Doing
if(foo){
bar
}
instead of
if(foo)
bar
could eventually prevent
if(foo)
bar
dot
I can't really think of any language I know where omitting an unnecessary else can lead to potential errors :-?
there are a lot of "words" telling you the way to programming such as DRY
in this case i'd use YAGNI.. you aint gonna need it..
so following this you shouldn't write the else.
anyhow in my opinion it makes it harder to read and understand the code.. the more you write the harder to understand the code is
edit:
here are the links you requested:
http://en.wikipedia.org/wiki/YAGNI
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Resources