How to put a case statement into {} - swift

Okay So I am working on a project and trying to make it neat and visibly understandable where everything is is difficult. To my knowledge Xcode doesn't have an Indent Guide, but something is does have is the ability to collapse the code inside {} like this:
This can work for any {}. I want to make my code easier to read, so I am trying to use this effect inside of a case, so it is easier to see all of the cases at once, I did this:
switch transition {
case .SlideOutside:
{ /* Error */
print("Pretend that there is hundreds of lines of code here.")
}
break
default: //The Default will be Fade
break
}
But I get the error
Braced block of statements is an unused closure
On line 4 with the opening bracket. I don't know how to fix this, could somebody please help.

This sentence
and trying to make it neat and visibly understandable
and this one
Pretend that there is hundreds of lines of code here.
are not very compatible :)
Solution 1
Writing
{
/* Error */
print("Pretend that there is hundreds of lines of code here.")
}
you created a closure but you did not run it. To execute the block you need to add () like shown below
{
/* Error */
print("Pretend that there is hundreds of lines of code here.")
}()
Solution 2
If you really are putting hundreds of lines inside a switch case I think you should better struct you code.
The first thing to do is moving all that code inside a function in order to put only the invocation of the function inside the Switch Case.
switch transition {
case .SlideOutside: slideOutInside()
default: fade()
}
Next you should look at that function with hundreds of line and manage ti split it into subfunctions (and so on).

Related

Are commands supposed to do "nothing" in some cases

In my opinion there basically exist two different methods:
commands and gets (queries) voids and returns.
I often encounter following situation:
A void method (command) is called. When I see the implementaion, I notice
that this method not always actually does something depending on some special conditions or something.
Consider this example:
caller.NotifyCustomer();
NotifyCustomer()
{
if(weather.IsNice || moon.IsShining)
{
return;
}
Notify();
}
My problem with code like this is that the caller obviously has a clear intention: He wants to notify a customer.
But the method itself does not always actually notify the customer.
In my opinion this is confusing. I would not expect this behaviour by just reading the method name.
I could rename the method to somewhat like NotifyCustomerIfApplicable
but this does not seem to be very handsome either.
Another option would be to check for those special conditions before calling the actual method NotifyCustomer(), by extracting the if evaluation in a seperated method that can be called before.
But this isn't really nice either I guess.
Is there a clear recommendation?

Unexpected behavior in nested recursive function

I have some code that behaves rather strangely.
I am inside a function, and I declare a nested one, which should check if something isn't okay. If it's not then it should sleep for five seconds and call itself again.
sub stop {
sub wait_for_stop {
my $vm_view = shift;
if ( $vm_view->runtime->powerState->val ne "poweredOff" ) {
debug("...");
sleep(5);
wait_for_stop();
}
}
debug("Waiting for the VM to stop");
wait_for_stop( #$vm_views[0] );
}
So, in the call that results in the recursion inside the if condition, if I put the parameter (as the function definition expects it), like this:
wait_for_stop($vm_view);
I get an infinite loop.
If I leave it without a parameter, as in the code example above, it works as expected.
Shouldn't $vm_view in the subsequent calls be empty? Or the last used value ($vm_view->runtime->powerState->val)? Either case should result in unexpected behavior and error.
But it works without any parameter. So why is that? Is there something I've missed from perldoc?
EDIT1: Actually, the value of $vm_views does get changed, so that's not the reason for the infinite loop.
General clarifications
I am using the VMware SDK. The $vm_views object contains the VM details. I am polling one of its methods to detect a change, in this particular case, I need to know when the machine is turned off. So, for lack of a better way, I make a call every 5 seconds until the value is satisfactory.
My purpose is to stop the VM, make modifications that can only be made while it's off, and then launch it.
Actual question
When I don't pass a parameter, the block works as expected – it waits until the value is poweredOff (the VM is off), and continues, which doesn't make much sense, at least to me.
In the case I put $vm_view as parameter, I get an infinite loop (the value will still get changed, since I'm calling a method).
So I am wondering why the function works, when after the first call, $vm_view should be undef, and therefore, be stuck in an infinite loop? [undef ne "poweredOff" -> sleep -> recursion till death]
And why, when I pass the expected value, it gets stuck?
PS: To all those saying my recursion is weird and useless in this scenario – due to a myriad of reasons, I need to use such a format (it's better suited for my needs, since, after I get this bit working, I'll modify it to add various stuff and reuse it, and, for what I have in mind, a function seems to be the best option).
You should always look at your standard tools before going for something a little more exotic like recursion. All you need here is a while loop
It's also worth noting that #$vm_views[0] should be $$vm_views[0]) or, better, $vm_views->[0]. And you don't gain anything by defining a subroutine inside another one -- the effect is the same as if it was declared separately afterwards
An infinite loop is what I would expect if $vm_view->runtime->powerState->val never returns poweredOff, and the code below won't fix that. I don't see any code that tells the VM to stop before you wait for the status change. Is that correct?
I don't understand why you say that your code works correctly when you call wait_for_stop without any parameters. You will get the fatal error
Can't call method "runtime" on an undefined value
and your program will stop. Is what you have posted the real code?
This will do what you intended. I also think it's easier to read
use strict;
use warnings;
my $vm_views;
sub stop {
debug ("Waiting for the VM to stop");
my $vm_view = $vm_views->[0];
while ( $vm_view->runtime->powerState->val ne 'poweredOff' ) {
debug('...');
sleep 5;
}
}
I think you would have a better time not calling wait_for_stop() recursively. This way might serve you better:
sub stop
{
sub wait_for_stop
{
my $vm_view = shift;
if ($vm_view->runtime->powerState->val ne "poweredOff")
{
debug("...");
#sleep(5);
#wait_for_stop();
return 0;
}
return 1;
}
debug ("Waiting for the VM to stop");
until(wait_for_stop(#$vm_views[0]))
{
sleep(5);
}
}
Your old way was rather confusing and I don't think you were passing the $vm_view variable through to the recursive subroutine call.
Update:
I tried reading it here:
https://www.vmware.com/support/developer/viperltoolkit/doc/perl_toolkit_guide.html#step3
It says:
When the script is run, the VI Perl Toolkit runtime checks the
environment variables, configuration file contents, and command-line
entries (in this order) for the necessary connection-setup details. If
none of these overrides are available, the runtime uses the defaults
(see Table 1 ) to setup the connection.
So, the "runtime" is using the default connection details even when a vm object is not defined? May be?
That still doesn't answer why it doesn't work when the parameter is passed.
You need to understand the VM SDK better. You logic for recursion and usage of function parameters are fine.
Also, the page: https://www.vmware.com/support/developer/viperltoolkit/doc/perl_toolkit_guide.html
says -
VI Perl Toolkit views have several characteristics that you should
keep in mind as you write your own scripts. Specifically, a view:
Is a Perl object
Includes properties and methods that correlate to the properties and
operations of the server-side managed object
Is a static copy of one or more server-side managed objects, and as
such (static), is not updated automatically as the state of objects
on the server changes.
So what the "vm" function returns is a static copy, which can be updated from the script. May be it is getting updated when you make a call while passing the $vm_view?
Old Answer:
Problem is not what you missed from Perl docs. The problem is with your understanding of recursion.
The purpose of recursion is to keep running until $vm_view->runtime->powerState->val becomes "PoweredOff" and then cascade back. If you don't update the value, it keeps running forever.
When you say:
I get an infinite loop.
Are you updating the $vm_view within the if condition?
Otherwise, the variable is same every time you call the function and hence you can end up in infinite loop.
If I leave it without a parameter, as in the code example above, it
works as expected.
How can it work as expected? What is expected? There is no way the function can know what value your $vm_view is being updated with.
I have simplified the code, added updating a simple variable (similar to your $vm_view) and tested. Use this to understand what is happening:
sub wait_for_stop
{
my $vm_view = shift;
if ($vm_view < 10){
print "debug...\n";
sleep(5);
$vm_view++; // update $vm_view->runtime->powerState->val here
// so that it becomes "poweredOff" at some point of time
// and breaks the recursion
wait_for_stop($vm_view);
}
}
wait_for_stop(1);
Let me know in comments how the variable is being updated and I will help resolve.

What's a good maintainable way to name methods that are intended to be called by IBActions?

I am creating function (for example) to validate content, then if it is valid, close the view, if it is not, present further instructions to the user. (Or other such actions.) When I go to name it, I find myself wondering, should I call it -doneButtonPressed or -validateViewRepairAndClose? Would it be better to name the method after what UI action calls it, or name it after what it does? Sometimes it seems simple, things like -save are pretty clear cut, other times, and I can't thing of a specific example right off, but I know some have seemed like naming them after what they do is just so long and confusing it seems better to just call them xButtonPressed where x is the word on the button.
It's a huge problem!!! I have lost sleep over this.
Purely FWIW ... my vote is for "theSaveButton" "theButtonAtTheTopRight" "userClickedTheLaunchButton" "doubleClickedOnTheRedBox" and so on.
Generally we name all those routines that way. However .. often I just have them go straight to another routine "launchTheRocket" "saveAFile" and so on.
Has this proved useful? It has because often you want to launch the rocket yourself ... in that case call the launchTheRocket routine, versus the user pressing the button that then launches the rocket. If you want to launch the rocket yourself, and you call userClickedTheLaunchButton, it does not feel right and looks more confusing in the code. (Are you trying to specifically simulate a press on the screen, or?) Debugging and so on is much easier when they are separate, so you know who called what.
It has proved slightly useful for example in gathering statistics. The user has requested a rocket launch 198 times, and overall we've launched the rocket 273 times.
Furthermore -- this may be the clincher -- say from another part of your code you are launching the rocket, using the launch-the-rocket message. It makes it much clearer that you are actually doing that rather than something to do with the button. Conversely the userClickedTheLaunchButton concept could change over time, it might normally launch the rocket but sometimes it might just bring up a message, or who knows what.
Indeed, clicking the button may also trigger ancillary stuff (perhaps an animation or the like) and that's the perfect place to do that, inside 'clickedTheButton', as well as then calling the gutsy function 'launchTheRocket'.
So I actually advocate the third even more ridiculously complicated solution of having separate "userDidThis" functions, and then having separate "startANewGame" functions. Even if that means normally the former does almost nothing, just calling the latter!
BTW another naming option would be combining the two... "topButtonLaunchesRockets" "glowingCubeConnectsSocialWeb" etc.
Finally! Don't forget you might typically set them up as an action, which changes everything stylistically.
[theYellowButton addTarget:.. action:#selector(launchRockets) ..];
[theGreenButton addTarget:.. action:#selector(cleanUpSequence) ..];
[thatAnimatingButtonSallyBuiltForUs addTarget:.. action:#selector(resetAll) ..];
[redGlowingArea addTarget:.. action:#selector(tryGetRatingOnAppStore) ..];
perhaps that's the best way, documentarily wise! This is one of the best questions ever asked on SO, thanks!
I would also go with something along the lines of xButtonPressed: or handleXTap: and then call another method from within the handler.
- (IBAction)handleDoneTap:(id)sender {
[self closeView];
}
- (void)closeView {
if ([self validate]) {
// save and close
}
else {
// display error information
}
}

Debugging loops

For some current projects, I'm working with several data structures that are pretty large (in the area of 10K elements). To be able to access this data in lists, I need to use loops and iterators, which can be a pain when the problem area is in the latter half of the list.
So I find myself spending alot of time with my finger on the F8 button in Eclipse's debugger to loop through each element of an iterating loop. This gets worse when have to step through that particular section several times to get an idea why the code is reacting a particular way.
If one has a general idea how many times a loop is to execute before a problem area is hit, is there a way to set a loop breakpoint to execute up to that point then pause?
Use conditional breakpoints.
http://wiki.eclipse.org/FAQ_How_do_I_set_a_conditional_breakpoint%3F
I believe there's a better way to do this, but you can create a trivial block of code in the loop that only executes at a certain iteration, and put the breakpoint inside of it.
if (loopIndex == 1000) {
int number = 14; //Break here
}
Using this as an example:
for(int i=0;i<10000;i++){
System.out.println(i);
}
Set a breakpoint on the print line, then right click on it and select Breakpoint Properties.... From here you can set a condition to trigger the breakpoint. This is the similar to a conditional you would have in an if-statement. If you wanted to trigger the breakpoint when i equals 6000, check the Conditional box and try this:

A shot in the dark - Application bug

Ok so this is gonna be a bit of a shot in the dark without you being able to see my application!
I have a bug. I have a SwimmingPool class, my app passes the pool from a tableview into a detail view where you can see all the swimmingPool class fields. You can then click on the individual detail, edit it, and then save it. The 'original' pool facility is copied and passed to the view controller responsible for actually making changes. If the user presses save, the fields are copied from the copy into 'original'
switch (self.sectionFromParentTable) {
case KNameIndex:
self.thePoolFacility.name = self.thePoolFacilityCopy.name;
self.thePoolFacility.type = self.thePoolFacilityCopy.type;
break;
case KAddressIndex:
self.thePoolFacility.address = self.thePoolFacilityCopy.address;
break;
case KPhoneNumberIndex:
self.thePoolFacility.phoneNumber = self.thePoolFacilityCopy.phoneNumber;
break;
case KWebAddressIndex:
self.thePoolFacility.webAddress = self.thePoolFacilityCopy.webAddress;
break;
case KPricesIndex:
self.thePoolFacility.prices = self.thePoolFacilityCopy.prices;
break;
case KPoolIndex:
self.thePoolFacility.pools = self.thePoolFacilityCopy.pools;
default:
break;
}
[self.navigationController popViewControllerAnimated:YES];
Can I have some guesses at a bug that does the following:
The bug results in the changes done
to a class' fields not being saved. In particular a class called TimeEntry, in a mutable array called Monday in a Dictionary called TermTimes in a class called pool and then in a mutable array called Pools.
It's appears random. Sometimes it
works perfectly. Sometimes it
doesn't! I can't recreate the error,
only if I'm lucky can i get it not
to save. My hunch is it could be
time sensitive. For example, If I am
entering a timetable for Pool
opening times, if i quickly add a
few entries and save it usually
works fine. If I fill in a whole
timetable then it more than not
doesn't save.
The app doesn't crash.
It's infuriating the try and debug an error that seems to happen at random. Any hints on such an epic bug hunt?
One of the best ways to tackle this type of problem (where it seemingly can't be reproduced reliably) is to insert logging code in various areas where you expect certain things to be happening. Log places that errors could occur, log what values you are expecting and what you have, etc. Next, try, try, try until you can reproduce the bug.
Unlike before, you now have a log to look at and see where things went wrong. If things still look correct everywhere, insert some more logging code elsewhere. If you see something go wrong, but don't understand it, put more logging code in that area and keep narrowing the problem down.
Hopefully this will lead to new hypotheses about how the bug happens, and you will be able to reproduce it under the debugger reliably and fix it!
As duffymo mentioned, multithreading could be the culprit, and would be a good place to investigate first if you're knowingly using multiple threads.
"random" and "hard to reproduce" makes me think that this is an issue having to do with multi-threading. Race conditions are very hard to reproduce and debug. You'll need to make sure that you have exclusive rights to the resources you need to perform this operation.
My suggestion is to look for nils. Any method call on a nil object simply does nothing and returns nil, so any time you're expecting a method to be called and it isn't, you should look for that. (.foo = is the same as setFoo:, so nil.foo = 1; will do nothing.)
Thanks for all your answers. It's now fixed.
For those interested I'd forgotten to add a cellidentifer in the XIB of my cell subclass.
cellForRow: method was therefore creating a new cell every time. The memory got filled up very quick. It then seemed as though my app was automatically trying to cut the fat by forcing another tableView out of editing mode and not managing my instances properly.
Again it's a memory problem. Isn't this always the case!?!
The clue was a one off 101 error in the console indicating my app was using too much memory. Oh and a slow scrolling tableView.