For C#, JetBrains ReSharper often suggests that you invert your if statements to reduce the number of nested if-statements.
For example, it suggests that the code below:
private void Foo()
{
if (someCondition)
{
// Some action
}
}
could be converted to:
private void Foo()
{
if (!someCondition) return;
// Some action
}
Is there a similar way to do this with VHDL code? Even if it is possible, is there a good reason to avoid this coding style in VHDL?
I am wondering if it possible to achieve something like this in VHDL
process(clock)
begin
if (rising_edge(clock)) then
-- Some action
end if;
end process;
becomes
process(clock)
begin
if (not rising_edge(clock)) then
return;
end if;
-- Some action
end process;
Naturally there is no early return from a VHDL process because you don't return from a process...
In addition to early return from a subprogram (procedure or function) there are similar approaches to help structure loops : exit (terminating the loop) and next (terminating the current iteration).
These can be embedded in if statements as in your example but there's a more convenient and readable form :
loop
...
exit when A = '1';
...
next when B = '1';
...
end loop;
Don't.
not rising_edge(clock) is not guaranteed to be synthesizable by the IEEE standard for synthesizable logic. If you know of any tools that do synthesize this, I would be interested to know.
Also, you won't gain anything because (as stated by other repliers) the return statement is not valid in a process.
Try it: Even though this particular style won't work, it was a fair suggestion.
If you want to learn about out non-traditional ways of writing code the best way is to write it, simulate it and synthesize it. By experimenting, you will learn a lot and end up to be the smartest designer on your team.
The strategy you suggest is called early return because you are returning from a function early,
before reaching its end. It can be done in VHDL and it is as useful as in other languages, but the downside is that it can only be used in subprograms. You cannot "return" from a process.
In theory, you could move the code from inside your process to a procedure, but it would not help achieve what you want. I suggest that you read section 6.3 - Concurrent Procedure Call Statements
from Ashenden's Designer's Guide to VHDL to understand the details. In short, there are many restrictions to how the wait statement can be used in a procedure.
What's the point? (Does Resharper describe why you want to do this?)
My thoughts on doing this in VHDL-land:
In synthesisable code, it is very likely that - whatever shenanigans you pull to "optimise" your logic - if it turns out to be the same function, the synthesiser will (almost) always (in my experience) find the logic equivalency that mean it ends up with the same optimal logic for the same function as when you write it the straightforward way. (Counter-examples welcome!)
In tetsbench code, I guess you might be able to same some cycles?
From a code-readability perspective: there might be a gain, but if you have that many nested ifs maybe your overall structure needs a re-think...
Related
I am making a simple text game in pascal (a real beginner one). There is a general routine, that is repeated several times (the cycles variable, representing the levels). In the beginning of the routine there is a part where character`s name is asked. If the general repeat loop is complete or aborted at some level(1-4), the game goes back to the first sort of menu. I want the name to be asked only the first time, but, of course, I get the "variable "cycles" does not seem to be initialized" warning. Is there a way to restructure the code to avoid it?
Thanks.
The code excerpt (unnecessary details left behind):
program rpg_text_game;
var
game_action:char;
name:string;
cycles:1..5;
begin
repeat
writeln('Welcome to the game.');
writeln('To continue press "g",');
writeln('to read the license of this game press "i",');
writeln('and to quit press "q" and "enter": ');
readln(game_action);
case game_action of
'i', 'I':
{shows license}
'g', 'G':
{game begins}
if not (cycles in [2,3,4,5]) then
begin
writeln('Please enter your name: ');
readln(name);
end;
repeat
cycles:=1; //is initialized here
{actual game process - score is calculated based on *cycles* amount, that adds +1 with each tick ("if success then cycles:=cycles+1")}
{cycles - 1,2,3,4,5}
writeln('Do you want to try again, y/n?');
readln(game_action);
until(game_action='n') or (game_action='N');
until (game_action='q') or (game_action='Q');
writeln();
writeln('Press enter to quit');
readln();
end.
So, how to initialize/change the cycles variable (or even any other) to avoid that message and not to cheat by turning off the compiler hint option?
If cycles is a global variable, like in your example code, then simply do, in the main block of the program, before you start anything:
begin
cycles := 1;
game_action := Chr(0);
{ etc... }
...
end.
That is how you generally initialize global variables: in the main begin/end. block. Some versions of Pascal also allow (for global variables):
var
cycles: 1..5 = 1;
{ etc... }
but others don't. I don't know if your Pascal allows it. If it does, you won't have to initialize in the main block anymore. But note that that probably doesn't work for local variables of a function or procedure. There, you will probably have to use the (outer) begin/end; block of the function or procedure.
FWIW, the main block of a program can usually be found at the very end of the program, after all the const, type, var, procedure and function declarations and it ends with a dot (.).
Also note that the comment is right: split your program into separate functions and procedures, each with their own single task, and pass any information necessary to them. Do not write monolithic blocks of code. That is hard to read and hard to maintain. For instance, for each (or most) of your case items, create a separate procedure with the necessary parameters and call those from your case statement. That makes your code much easier to read, also for you.
In the first iteration of the loop in the code as is, cycles is read (by the IF NOT (cycles in [])) before being initialized. The compiler rightfully emits a warning for that.
The solution is simple, initialize it before the first REPEAT, or if you go more object pascal style, like Rudy says.
I'm searching the verilog equivalent of the VHDL attribute my_signal'last_eventbut in Verilog. I have googled it without success. Does someone know how to do it ?
The 'last_event attribute is used to know the time since the signal last event.
For example, if at time 15us, signal toto toogles from 0 to 1.
Then at time 20us, toto'last_event returns 5us.
Have you tried looking into some of the verilog system tasks? Specifically the following:
$time; // Return current simulation time in 64-bit integer
$monitor("format", v1, v2, ...); // Invoke only once, and execute (
// automatically when any of the
// variables change value.
You can look at the 'nested-if-else-if' example here http://www.asic-world.com/verilog/vbehave2.html for an example of a test bench that uses these.
You could create a time variable and update it whenever the signal changes
time my_signal_last_change;
always #(my_signal) begin
my_signal_last_change = $time;
end
This works in SystemVerilog; not sure if it would in verilog (you can try changing time to reg[63:0] in case it doesn't)
I was looking for a Ruby code quality tool the other day, and I came across the pelusa gem, which looks interesting. One of the things it checks for is the number of else statements used in a given Ruby file.
My question is, why are these bad? I understand that if/else statements often add a great deal of complexity (and I get that the goal is to reduce code complexity) but how can a method that checks two cases be written without an else?
To recap, I have two questions:
1) Is there a reason other than reducing code complexity that else statements could be avoided?
2) Here's a sample method from the app I'm working on that uses an else statement. How would you write this without one? The only option I could think of would be a ternary statement, but there's enough logic in here that I think a ternary statement would actually be more complex and harder to read.
def deliver_email_verification_instructions
if Rails.env.test? || Rails.env.development?
deliver_email_verification_instructions!
else
delay.deliver_email_verification_instructions!
end
end
If you wrote this with a ternary operator, it would be:
def deliver_email_verification_instructions
(Rails.env.test? || Rails.env.development?) ? deliver_email_verification_instructions! : delay.deliver_email_verification_instructions!
end
Is that right? If so, isn't that way harder to read? Doesn't an else statement help break this up? Is there another, better, else-less way to write this that I'm not thinking of?
I guess I'm looking for stylistic considerations here.
Let me begin by saying that there isn't really anything wrong with your code, and generally you should be aware that whatever a code quality tool tells you might be complete nonsense, because it lacks the context to evaluate what you are actually doing.
But back to the code. If there was a class that had exactly one method where the snippet
if Rails.env.test? || Rails.env.development?
# Do stuff
else
# Do other stuff
end
occurred, that would be completely fine (there are always different approaches to a given thing, but you need not worry about that, even if programmers will hate you for not arguing with them about it :D).
Now comes the tricky part. People are lazy as hell, and thusly code snippets like the one above are easy targets for copy/paste coding (this is why people will argue that one should avoid them in the first place, because if you expand a class later you are more likely to just copy and paste stuff than to actually refactor it).
Let's look at your code snippet as an example. I'm basically proposing the same thing as #Mik_Die, however his example is equally prone to be copy/pasted as yours. Therefore, would should be done (IMO) is this:
class Foo
def initialize
#target = (Rails.env.test? || Rails.env.development?) ? self : delay
end
def deliver_email_verification_instructions
#target.deliver_email_verification_instructions!
end
end
This might not be applicable to your app as is, but I hope you get the idea, which is: Don't repeat yourself. Ever. Every time you repeat yourself, not only are you making your code less maintainable, but as a result also more prone to errors in the future, because one or even 99/100 occurrences of whatever you've copied and pasted might be changed, but the one remaining occurrence is what causes the #disasterOfEpicProportions in the end :)
Another point that I've forgotten was brought up by #RayToal (thanks :), which is that if/else constructs are often used in combination with boolean input parameters, resulting in constructs such as this one (actual code from a project I have to maintain):
class String
def uc(only_first=false)
if only_first
capitalize
else
upcase
end
end
end
Let us ignore the obvious method naming and monkey patching issues here, and focus on the if/else construct, which is used to give the uc method two different behaviors depending on the parameter only_first. Such code is a violation of the Single Responsibility Principle, because your method is doing more than one thing, which is why you should've written two methods in the first place.
def deliver_email_verification_instructions
subj = (Rails.env.test? || Rails.env.development?) ? self : delay
subj.deliver_email_verification_instructions!
end
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.
I am working with Delphi. Does it make any difference in performance if we write if condition in different ways? For example:
if (condition) then
someVar := someVal
else
someVar := someOtherVal;
Or we can write:
if (condition) then begin
someVar := someVal;
end else begin
someVar := someOtherVal;
end;
I prefer the second option just because it looks better than the first one.
No, there is no difference in performance, the code created will be identical.
An aspect that might be more important than that the second option looks nicer, is that it is better for maintainence. If you need to add another statement in the else block, you will not accidentally forget to add the begin and end, which would put the statement outside the if and always be executed.
This will not make a difference in performance.
begin and end tell the compiler where a block of code starts and finishes, but no computation needs to be done there.
Begin and End do not slow down your code, as others have already said. I am writing another answer to encourage you even more explicitly to ALWAYS use begin and end whenever you could use them.
It is good to be liberal with using Begin and End, and not worry about them slowing you down (because they don't).
If you go the other way, and leave out begin and end wherever you can, you get into a different type of trouble.
This has happened to me lots. You can get in trouble when you insert a line into a place where no begin and end statement exist. You then end up scratching your head wondering what you did that broke your code. Begin-end-everywhere, even where not needed, is standard operating procedure for a lot of Delphi coders.
The only thing you should keep in mind about if-elseif-else is to keep the common cases up in your code before edge cases, so that the least possible conditions are evaluated.