|
My approach is similar. I call it the "diamond cutter method". I write the best code I can but, once finished, I look back and find better ways. Once this set of changes is done, I look again and see what can be improved. Like the apocryphal Michelangelo quote: "just remove everything that is not David". Disclaimer: I'm no Michelangelo and none of my code is David 
Corollaries:
1. My oldest code is my best code because it's been through so much polishing
2. My code is never finished
3. I cannot write the same code twice: the second time I find a better way.
Mircea
|
|
|
|
|
A sensible approach, I have to say.
The simple implementation is the (reliable) reference for all the following clever code.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I do that myself. Our products are large, so it's inefficient to try out something new. Many times I'll write a command line or GUI program to act as a test bed for the concept I'm working on. Most of the time I end up with source code that can be dropped into the product and hooked up with relatively little fuss.
Software Zen: delete this;
|
|
|
|
|
It is neither dirty, little nor is it secret, it seems most of us do this. I think the real trick is getting the newbie to refactor the code prior to production!
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Pete O'Hanlon wrote: start with naive implementations of code while I work out how I really want it to be laid out
I visualize it as stumbling...progress isn't usually in a straight line or graceful. 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Old saying -
First make it work.
Then make it work better.
|
|
|
|
|
Yeah, I'm with you - and, it seems, the majority.
I spend as little time as possible on initial code/changes. Which means I haven't made a huge commitment if I've ended up on the wrong track, or down a cul-de-sac. So it's easy to throw away some, (or all) of my work and start again.
It's a bit like getting lost when you're driving somewhere. [Yeah, some of us were driving before sat-nav!] The further you travel down the wrong road, the more you resist turning back. 
|
|
|
|
|
Hi. Pete,
i was fortunate enough to have an improbable journey to a career as a programmer beginning after i was ~39 years old (1982), and another, not unsuccessful, non-technical career in social work/psychology and academia.
Lucky to always be involved with prototyping, never shaped by whatever into top-down planning, flow-charts, Backus-Naur formalisms, Design Patterns, etc. ... of course, those are valuable, and often necessary (I learned much later). i can't imagine not bread-boarding code, trying to "divide and conquer," and create proof of concept from wiring together "mini-solutions." Of course, i "grew up" with no net, no CP, no Stackoverflow, often with documentation printed out in 3-ring binders 
i am sure when you do "clever" it is SOLID clever.Quote: Pete O'Hanlon wrote: We need to get better at telling new coders that this is okay.
Yes, but how, in the time of cut-and paste from SO and CP ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
I'm shocked, shocked! Do you mean to say that your code doesn't spring from your head full-grown, like Athena from the head of Zeus? 
Seriously, I suspect that everyone in the software field works in the manner you describe, especially those who claim otherwise. As a rule, the products we work on are simply too complex to be planned and built in a single step.
Hardware may differ. Many hardware projects are simple enough for the design and planning to be combined. Naturally, one must have the experience (i.e. have endured many failures) to be able to do this.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It's called refactoring, and there's nothing wrong with that. Programming is an iterative process.
Any time I look at code I wrote 10 years ago, I want to rewrite it.
Of course, there's some who will constantly fiddle with working code - the key is to recognize when that's what you're doing, and stop it.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
I wonder how many "Me too" responses there are here. Might make a decent survey question.
Me too, btw.
|
|
|
|
|
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.
|
|
|
|
|
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 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 do the same thing...
I have come to call it Regressive Analysis.
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
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."
|
|
|
|
|
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 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.
|
|
|
|
|
Just as I finally managed to wean some people off of IE and onto Edge last year (yes, it took 'em that long), now Edge is nagging them to get off of Win7 and onto something newer as the browser will no longer update itself on that OS.
Realize that changing browsers is a big deal for some people. Now I'm being asked to get them used to a whole new OS. Which is gonna be a pig on old hardware, which is performing otherwise just fine with Edge + Win7.
Chrome isn't an option (I'm looking at their support page right now) as the last version to support 7 is 109, which came out exactly a month ago today.
The Firefox support page for the latest (109.0.1 as of this writing) says it supports 7. I don't think switching these folks over to FF is gonna be a good option anyway if I'm gonna have to find yet another alternative a few months down the road (I'm looking at a page suggesting August 2023).
This is perfectly capable hardware, and runs Windows 7 just fine even with recent browsers. I know the hardware won't perform as well with 10 (and 11 has its own (totally artificial) requirements).
In terms of hardware requirements, Linux might be an interesting alternative. But not for these people. I'm out of ideas. These folks can't afford new hardware "just because" browser makers no longer want to bother supporting 7.
What OS feature are modern browsers relying on anyway that they can't keep supporting 7? Security? Let them agree to a disclaimer and let them carry on with their lives.
|
|
|
|
|
dandy72 wrote: disclaimer
Eh? disconinued support means exactly that: "May or may not work on 7"
[EDIT] sorry, I reread your post. I am pretty sure updates would break your old browser. They simply do not examine if it will break or not. Why not be happy with an un-updated browser ?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Updates are the problem, not the solution.
|
|
|
|
|
Yes. And I said: why not avoid updates?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
