Return to “Dev Logs”

Post

Re: [Adam] Thursday, February 15, 2018

#196
DoctorGester wrote:
Tue Feb 27, 2018 4:14 pm
Aight, I got it now, then yeah.

You surely do have functions where you manipulate data and use local variables though?
Not very often at all, most of them are stored in the global object.
This makes it easier for me to alter settings on the fly without altering on disk files.

Though I don't *really* need to worry about that, as the entire code, baring a single function, is reloadable, from source, on the fly. :D
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: [Adam] Thursday, February 15, 2018

#198
lobosan wrote:
Wed Feb 28, 2018 3:58 pm
Sorry if I have hurt your feelings, mcsven :(
It's just, VBA/ASP let me get away with a mess and bad habits I had to unlearn.
Javascript is the same for me.
I had a really good habit of using ; after every line with PHP.
Then lost it with JS.

Slowly trying to get used to always using ; on everyline even in JS now.
Takes SOO long to relearn.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: [Adam] Thursday, February 15, 2018

#202
DigitalDuck wrote:
Thu Mar 01, 2018 7:56 am
Flatfingers wrote:
Thu Mar 01, 2018 12:41 am
I also intend to continue wrapping return values in parentheses:

return(value);
I don't do this for single variables or values, but if I'm returning anything more complex I always wrap it in parentheses. It doesn't feel right to do

return i * 2;

and I have no idea why.

Maybe it's just the voice of experience. "If it's a thing I can control, I must do so, rather than letting the compiler/interpreter writer do a thing I might not have anticipated."



Actually... this is not in any way a criticism, just a kind of odd observation, but -- this side-track into discussion of how to end functions reminds me of a couple other coding quirks that I persist in using:

1. I never return anything other than a single value. In nearly every case this means doing all my calculations and/or concatenations before the end of the function, and putting the final value to be returned into a variable then returning that variable.

If I still coded down to the metal or needed to save bytes (some of my first programming was done in 3.5K of RAM), I might not do this to avoid the cycles or memory needed for another variable. But it feels like those days are long past. So since then I've preferred to emphasize clarity. Returning a variable rather than an operation just feels a little safer, as though it forces me to be more specific about what I'm returning. That might be only a perception, though.

2. I never have more than one return() in a function. I will literally design the logic of my code such that there is never more than one return() in any code I write, and it is always the very last statement of the function.

This comes from being burned, originally in my own code but occasionally when having to work with the code of other people, by a stealth return() buried somewhere in the middle of a function. I hate wasting the time and focus needed to remember, "Oh, yeah, for this function, but not that one, I return half-way through."

By always structuring my logic so that there's always only one return(), and it's always the final statement, the high-level logical path for every function feels a little easier to keep straight in my head. In theory, this might result in some tortured logic, but in [mumblety-mumble] years of programming I can't think of any time when this happened. The worst that ever happens is that I have to declare a return code variable, and then instead of returning immediately put the appropriate return code into its variable holder, test it in the place where I would have returned, and as the "else" of that test fall through to the end of the function where the return() lives. It does add a variable that I have to be aware of, but the payoff is that I'm guaranteed there's only one place where the function returns to its caller.

Again, that there's any value in this might be just perception on my part, so I'm sort of nervously curious what some of the other (and better) coders here think of this quirk.
Post

Re: [Adam] Thursday, February 15, 2018

#203

Code: Select all

void validateInputAndDoStuff(BigThing input) {
	ChildA a = input.getChildA();
	
	if (a != null) {
		ChildB b = a.getChildB();
		
		if (b != null) {
			ChildC c = b.getChildC();
			
			if (c != null) {
				doStuff(c);
			}
		}
	}
}
Instead of

Code: Select all

void validateInputAndDoStuff(BigThing input) {
	ChildA a = input.getChildA();
	
	if (a == null) {
		return;
	}
	
	ChildB b = a.getChildB();
		
	if (b == null) {
		return;
	}
	
	ChildC c = b.getChildC();
	
	if (c == null) {
		return;
	}
	
	doStuff(c);
}
Post

Re: [Adam] Thursday, February 15, 2018

#207
AdamByrd wrote:
Thu Feb 15, 2018 2:11 pm
[*]Attached very quiet cantina music to asteroids and watched Lindsey go slightly insane trying to figure out why she has Star Wars stuck in her brain.
THIS WAS SO FUNNY OMG

this is the story i'm going to tell when I receive my extremely specific award for Best Space Ships Generated From Scratch
Ship Inspiration Pinterest!! (send me stuff)

"You’ve got to work on something dangerous. You have to work on something that makes you uncertain. Something that makes you doubt yourself... because it stimulates you to do things you haven’t done before. The whole thing is if you know where you’re going, you’ve gone, as the poet says. And that’s death."
- Stephen Sondheim
Post

Re: [Adam] Thursday, February 15, 2018

#210
AdamByrd wrote:
Thu Feb 15, 2018 2:11 pm
Actions 'eat' the input so only the most recently added action will be triggered which allows us to push sets of actions onto a stack.
Can you elaborate on this a little, I seem to be missing something. Say I were to map "ActionA" => Spacebar on frame 3 and then map "ActionB" => Spacebar on frame 5. On frame 6 the Spacebar is pressed. According to the quote above, will only "ActionB" be seen by the system as actually occurring and only callbacks registered for "ActionB" will be called? Can you describe why this behavior is desirable as opposed to all actions mapped to a physical key having all their respective callbacks called?

Online Now

Users browsing this forum: No registered users and 6 guests

cron