|
34) ONYX - a stone: operating (ON) with axes(X,Y)
Good one! 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
I see @sanderrossel hasn't added a Sound of the Week (too much studying for that test?). For anyone who wants to warp their mind, here's an old classic that came up recently. Or for something not so warping that I'd never heard before, some new-ish Pop music. Have a great weekend!
|
|
|
|
|
|
|
Mark_Wallace wrote: Seriously?
Chill, Dude! Do the Salmon Dance!
|
|
|
|
|
fb and twitter fads ain't trippy; they're lowest-common-denominator marketing, which too many people fall for.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
 Hope your weekend goes better than your present, even if it needs chemicals to do so. Have a beer or something! That's a chemical or so! ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
|
|
|
|
|
Hey, I never touch "chemicals" -- but don't denigrate beer!
The only two liquids worth bothering with are beer and Tabasco sauce!
(But not simultaneously, obviously)
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
|
Hello,
I was curious if anyone has had experience using the MSIX packaging tool. Will this be a true successor to MSI Installs?
|
|
|
|
|
Sorry, but ms told me that it "provides a modern packaging experience", so I ran a mile.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
what happen to wiX?
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
I've never been convinced MSIX was necessary.
The "X" in MSIX seems out of place to me. It should be used to cross out the whole thing.
|
|
|
|
|
I have just had a heated argument cage fight lively discussion with some of my team members about ReSharper's suggestion of refactoring code to replace nested ifs with a series of multiple early return statements. This caused horribly messy code that ReSharper actually described in it's help as "more readable"!
Using a version of their example code (which is a lot simpler than the actual code in question):
void SomeFunction(SomeThing s)
{
if (s != null)
{
if (s.Thing != null)
{
.
.
.
}
}
}becomes:
void SomeFunction(SomeThing s)
{
if (s == null) return
if (s.Thing == null) return;
.
.
.
}This makes a complete hash of the natural flow of the code and introduces an execution statement (return) on the same line as the "if" which is bad coding practice, and then does it again, and then drops though to do some actual processing.
If I was to refactor the code it would do this:
void SomeFunction(SomeThing s)
{
if (s != null && s.Thing != null)
{
.
.
.
}
}or possibly:
void SomeFunction(SomeThing s)
{
if (s?.Thing != null)
{
.
.
.
}
}Which is a lot cleaner!
...and this isn't even considering a method that returns a value of some sort.
Opinions?
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I agree.
I will use multiple returns when doing otherwise would be less readable or less efficient, but otherwise I prefer one return.
And I don't listen to anyone who says that a throw or a yield is the same as a return.
modified 15-Feb-19 17:57pm.
|
|
|
|
|
I actually sometimes throw exceptions instead of just return and yes I prefer strongly the early returns. It's more modular than the nested hell of mess. Especially when multiple people add crap within a particular branch of ifs.
I looked at the source code of DOOM. John Carmack uses early returns. That should settle it.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Urban Cricket wrote: John Carmack uses early returns.
Looking at my bookshelf: The Graphics Programming Black Book, by Michael Abrash and with a foreword by John Carmack. Fearsomely thick tome, full of how to write fast graphics code.
That kind of processor cycle counting on a 386 or 486 is outdated, while the algorithmic optimizations remain as current as ever, especially if you are able to delegate them to the graphics processor. Early returns as a way to waste no processor cycle too much in a function is only rarely important anymore.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
That is true, but it has other benefits too. Generally as a principle I prefer within a piece of code, if the task is done within a branch it should exit immediately. Later these blocks can be moved out to separate methods or classes. I work in a team where a couple of the members like to add thousands of lines of code in a single method and management tends to let us do whatever we want. So on one hand I really like being left to do what I want in terms of programming style, on the other hand they don't let me lecture others on how to code
Usually I start a project, write the skeleton and after the first version they assign others to add features, which lead to those 1000 lines functions.Early returns help me with that. I just take that additional code and put it in a separate method or class
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Such long functions can be a pain, no matter what. Early returns definitely are better to follow than deeply nested code with some code blocks being dozens or even hundreds of lines long.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Unless you're an embedded developer trying to squeak out the quickest code on an underpowered processor. I was always getting projects with weenie processors and grandiose firmware requirements. It seems that the hardware engineer had a rather limited grasp on firmware development and how much space/speed would be required for the project. They eventually figured out that I should be involved in the processor and memory requirements selection.
|
|
|
|
|
I sure know that. My first computer had a hex keyboard and actually was very much like today's microcontrollers. And I still have it and use it, just to stay sharp.
Edit: Picture[^]
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I kind of wish I'd kept my first computer. It was a z80 S100 bus system where I wire wrapped all the boards except for the display card (16 lines by 64 character with a rf modulator to display on a TV). I had a 2kb monitor program (Zapple) that gave you the standard peek/poke memory, dump memory, input/output to I/O, run from an address and set break points. I use to knows most of the z80 instruction set by the numbers. Good times.
|
|
|
|
|
Great! The good old times never ended for me, partially because I would see it as a great loss if that old computer ever died, partially because such old tech is the is the only option to tinker around with as a hobby without getting poor. I'm certain you know what kind of equipment and knowledge is needed when you want to play around with the most modern stuff.
It's more interesting to overcome the limitations of the old stuff anyway. Modern chipsets do that for you, so where is the point in puzzling them together as intended? Why don't you grab a Z80 on ebay and build a new old computer to bring back the old times?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
