My dirty little coding secret
-
I often get my best ideas in the shower. It got so frequent I had one boss tell me the company should pay my water bill.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
For me, I usually get that "aha" moment at 3:00 AM. Forget about sleep after that.... 😳
-
I agree with you. Yes, yes... you read it right ;) ;P If it is something private... it is like v0, v00, v00+ until it gets to v1 in a nice form. If it is for work... I prefer to do like (I don't remember who told it but... anyways): If I have 8 hours to chop a tree, I will spend 6 hours sharpening my axe.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Nelek wrote:
Yes, yes... you read it right
:laugh: :laugh: :laugh:
Nelek wrote:
I will spend 6 hours sharpening my axe.
It just makes sense. Time and time again I've seen "spaghetti code" projects because folks don't take the time to do that.
Jeremy Falcon
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
I strive to write boring and basic code (to not confused with BASIC, that is a part of my past). Clever solutions are clever until they are not.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
Yep ... I've refactored, and factored back again. Created "new" routines I had already created (and forgot about). It's called: "Flow".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Guilty ;) I keep refactoring till I retire. I'm a C# developer. With every new version of the language, I look at my code to see where I can 'fit it in' the new stuff. I found a module last week that I refactored 98 times in the past 3 years. :cool: My mantra is: First make it work, the refactor it till it doesn't, and finally start over. :-D
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
My dirty little secret is that quite often I won't write functions unless that code is used exactly the same way in at least three other places. And if an existing function doesn't do exactly what I want it to I will create a new version rather than add a new parameter. Or (even worse) I will inline a copy of the entire (existing) function and modify it in the main body of my code. Why do I do this? Because after thousands of code walk-throughs I know it is easier for someone to understand a linear block of code. Every meaningful function call (i.e. a function call that changes something rather than just return something) or call-back reduces the comprehensibility of code.
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
It is the only way innovative code ever got written. The idea starts in your head and the structure that makes it work has to be coded up fast before it falls out of your head. At this stage I don't worry about public and private, const correctness or compiler warnings. I'm just interested in getting it all connected up so I have something to run and test. Then I go back and deal with const correctness etc. because that will help with writing the rest of the code. Nobody wants to admit that there isn't much between idea in head and working code.
-
Strange - I'm different. I generally try to "do it the right way" from scratch, even for one off throwaway jobs for me. Even when I was checking a prototype PCB (solder on the processor and enough ancillary bits of hardware to make it run and toggle a signal, then add a bit more and test that, ...) the code was "production quality" - if only because I got bitten too many times by throwing code together to see if hardware worked and eventually found it was the software not the hardware I was trying to debug! :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
There's a subtle difference between production ready, and functionally complete. It's (for me) always worth thinking through what the functionally complete (System Engineered) version could include and how it may become over complex with contradictory requirements. Sometimes there are subtle choices that lead to the death-march pit of doom while a slightly different choice would clearly signpost the sunlit uplands of future success. Then you can focus on the core element, the 'spike', where the tyres hit the road and the concepts hits the existing code, and neater approaches to the same functionality do start to emerge. Moving fast, always broken, like a bull in a china shop, is not a good look! Production ready is good, full function extendable is even better ;-)
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
That is a very wise way to approach something new. It lets you get basic functionality working ( and discovering any quirks or poor performing code). Then, especially if you use a repo so you can rollback an “experiment” easily, you can build on it. Refactor functionality as necessary to keep it somewhat atomic or genericize some of the code. Yours is a useful post to start my day.
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
Several coding secrets: 1) Being consistent -- Use the same naming convention, indentation, structuring, etc., throughout all code. 2) Small modules -- Typically 40-60 lines or so. 2a) Module on a page -- Look at a complete module without having to scroll/page through it. 3) But not too small -- Avoiding 1-3 lines of actual code as a function (nothing more ineffecient than looking at 10 lines to see something like "int GetAsValue() { return A; }" 4) Nothing fancy -- Avoid complex templates, macros, etc. 5) Adding some comments for relatively complex code, but avoiding unnecessary comments. 6) And, finally, frequent trips to the coffee pot, with associated trips to the men's room, to get the body moving and the blood circulating.
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
I do this, and I consider it part of *design*. It helps me come up with the algorithms that I need before I actually implement them for keeps.
To err is human. Fortune favors the monsters.
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
I do the same thing... I have come to call it Regressive Analysis.
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Strange - I'm different. I generally try to "do it the right way" from scratch, even for one off throwaway jobs for me. Even when I was checking a prototype PCB (solder on the processor and enough ancillary bits of hardware to make it run and toggle a signal, then add a bit more and test that, ...) the code was "production quality" - if only because I got bitten too many times by throwing code together to see if hardware worked and eventually found it was the software not the hardware I was trying to debug! :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
That is the Hardware way, going full Mandoliran. If you have to hardware tasks get one step at a time is best. I must admit once Visual Studio comes out very seems to be an expert and often tells you you are taking too long you don't need 'try ... catch', test it 'you screwed up with lenght that could be entered' out comes try...catch. :omg:
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
Agreed. When the problem is a difficult one, my first-cut solution will be complex. A beginning programmer might review the code and conclude "this guy is Smart! I could never write code like this." Then I take some time away, come back, boil it down and refactor into something clean and elegant. The same beginner would then review it and conclude "of course this is correct, this is the way I would have coded it."
-
That is the Hardware way, going full Mandoliran. If you have to hardware tasks get one step at a time is best. I must admit once Visual Studio comes out very seems to be an expert and often tells you you are taking too long you don't need 'try ... catch', test it 'you screwed up with lenght that could be entered' out comes try...catch. :omg:
This is the way. :-D
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
That is the Hardware way, going full Mandoliran. If you have to hardware tasks get one step at a time is best. I must admit once Visual Studio comes out very seems to be an expert and often tells you you are taking too long you don't need 'try ... catch', test it 'you screwed up with lenght that could be entered' out comes try...catch. :omg:
Out of interest, did you watch The Book of Boba Fett as well? I just finished bingeing it and am looking forward to series 2, if it ever happens.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
as a comparison to painting, many sketch a rough outline, then fill in, then maybe shift an arm, or even blank paint over the whole thing and restart knowing oh, i wanted the eye line pointing here, then refine, add detail few, very few and after many years of crafting get to drawing final lines first time. and fewer still start their carriers with being able to finial look first attempt of pure gold, might be a fluke and not saying it bad, but understanding WHY you did it that way can become more important of being able to intuit the solution but not explain.
-
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up. We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
i am a master at doing only the first part! as soon as i try to refactor... someone brings me some other fire. its rare that i get to feel happy with the code i did.
