|
Far too many assumptions implied.
|
|
|
|
|
Which is it, making code "look good" or writing "good code"? Because those are two completely different things.
Your available answers shouldn't be unrelated to the question.
|
|
|
|
|
|
No I don't feel pressure to make my code look as bad as the code I see online 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
|
"The best code I can" may or may not be "better than what I see online" (for example).
"Best" varies with timelines, how bright I am at that point in time, how well defined the project is, etc, etc. Also does "best" mean "most technically advanced," which is overkill for a lot of business needs, or "what best fits this situation"?
I try to write the most understandable, well-documented, and easy-to-refactor code I can at that particular time, given any limitations like time. I think that's all anyone can ask.
Invariably, you'll look back at code you wrote X time ago and think it's a pile of crap, because you've learned new things, have new perspectives, new requirements have come to light, and so on.
So, try to do today's best, but don't be afraid to refactor in the future. If your code has decent separation of concerns, refactoring shouldn't be a huge deal.
Of course, it usually is. Sigh.
|
|
|
|
|
Excellent!
Documentation is always up for grabs, but well understandable and well commented code is the definition of beautiful code. There was an individual (I don't know, a professor or something) that said that well written code does not require commenting - because it is obvious from the code. That is true most of the time, but when it comes to specific rules it it BS.
Best [code] has nothing to do with latest technology, it has to do with the code that manipulates the hardware [or data] to do what we want it to.
Most of the changes I have seen in the coding/language/frameworks changes over the years, has been a repackaging of ideas and knowledge that already existed.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
I write code with the idea that the person who will maintain it is a psychopath who knows where I live ...
My belief is that code should be efficient, easy to read, commented where the underlying business rule is not obvious, and as easy to debug is possible. That said, I feel no outside pressure to meet the standard.
|
|
|
|
|
Good! Although I consider myself a sociopath. Most people like me, once they know me, because they understand that I tend to be literal and think in logical terms. It took years to learn how to socialize without pissing someone off, because a told the literal truth as I saw it. Peoples egos are so fragile. I am more than willing to have a reasonable, calm, discussion, but don't lie to protect your pride - that leads to the dark path and loss of respect.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
I've been in the game long enough to have seen a long chain of coding styles defining "good" code. Those rules that are not contradicted by some other set of rules for "good" code are usually so obvious that you rarely think of it as a "rule".
What matters more than code is the system architecture and design. That is not stressed very much at all! I rarely see software that comes with an overall description of the modular structure, functional descriptions of the internal and external interfaces etc. Seeing how the source files are put into different directory branches is not documentation of the system architure and design! A header file is not a functional description of an interface - not even with a three line comment blurb per function.
When code is written according to a reasonably conisistent set of coding rules, formatted by a prettyprinter and verified by a high quality static analyzer, then the difference between code and code is minor. Fashions vary more than coders going by the same fashions. The real differences lie in architecture and design, not in coding.
|
|
|
|
|
I cannot entirely agree with that. I consider design and coding to be intricately linked; unless you are doing a very detailed functional design using flow charts, in which case the coders role is very limited. The quality of the implementation is reflected in the quality of the code. It is not a matter of beauty, even beautiful looking code can be full of bugs. But clean code (beautiful code) helps eliminate coding errors, regardless of the coding style.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
John R. Shaw wrote: I consider design and coding to be intricately linked; unless you are doing a very detailed functional design using flow charts, in which case the coders role is very limited.
From when I was working with protocols of the well-designed kind (read: OSI), I have had loved state/event driven models. However, most state model implementations are a crow's nest of if-elsesif or nested case statements; I never saw a framework for development of table driven code. So I started making my own ... but I switched jobs, and the whole thing was put in the drawer. Last Christmas, I found my 20+ years old design documents, brushed them up quite a bit, and my current hobby project is to complete that framework.
You are right: The coders' role is significantly reduced when a major part of the logic is put into a transition table, which defines a major part of the error handling as well - anything related to sequencing / protocol errors (which makes up a major part of runtime errors). A program code fragment handles a valid transition, and errors caused during that one transition. Transitions are by definition non-blocking and atomic, so any timing problems (race conditions etc.) are handled at the design level, reflected in the table, not in the the code. There is no other input than events; no intermediate input can scause an error during the transition. The transition logic itself (determining the next state, and for complex models: handling a set of substate variables) is handled by a common driver function (and for models with substates: Isolated bool functions on the substate variables). So the code is dramatically reduced both in size and complexity compared to other implementation methods. Essential complexity is moved into the transition table.
In my table framework, the tables are programming language independent. An editor manages the table of states, table of events, the transition table (states x events), table of event data types, as well as supporting tables for e.g. presentation styles. A state transition may call for actions such as raising events in other entities (objects). This code fragment may be specified in several languages; during the design, you may start out with a pseudocode description that any other language specification can be based on (but note that the code fragment, whether pseudo, K&R C, C#, Kotlin, ... handles actions for this single transition only).
Writing a generator to add all the required code blurb, extracting the appropriate code fragments from the tables, adding function headers, module definitions etc. is a one-time-task, and turns out to be quite simple. Obviously, the generator also provides a language specific driver for the transition table; this is really simple code that contains no application logic. From the tables the generator produces a set of source code files that may be fed into any compiler for the chosen language, complete with all red tape, and with definitions of required run time tables (e.g. the transition table, usually in a compacted form - tables of events and states usually have noe run time representation).
I haven't yet come as far as from a single table set generate implmentations in two different languages, having them cooperate over a communication channel; that will come some time this spring. When you then see how little the coder has to do, e.g. to create an implmenetation in a different language, you will see that indeed, the coders' role is reduced quite a bit. The major development work is in getting the transition table right.
Certainly: Designing software as atomic, instantaneous and non-blocking transitions requires a different approach than seeing objects as continously running processes. In may ways it is like going from GOTO-programming (or assembly JMP-instructions) to structured goto-less coding with for- and while-loops. Once you learn goto-less code, you love structured flow mechanisms. Once you learn to design flow logic, error handling and structure of cooperating entities as states and events, completely independent of language specific coding mechanisms, you learn to love that as well. In particular with respect to error handling.
|
|
|
|
|
Interesting; you have given me some new ideas. I have worked with some compiler-compiler generated state driven code bases before and they are mind boggling; when trying to analyze the flow. You have a warren case statements and other stuff to wade through.
Some years ago I created a state machine, in C++, whose design could conceivably be adapted to essentially accomplish the same thing. The majority of the code is generic (templates) in the since that it does not know or care what the basic_state derived object is doing - it just knows how to handle the specified response codes. To date, I have not determine the limits of what a state object should be allowed to do, because I have only used it for processing regular expressions.
One of the benefits of the design is that a state flow diagram can be generated - at run time. I used GraphVis, during development, to generate state flow diagrams. They came in vary handy for verifying expected verses actual flow.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
John R. Shaw wrote: One of the benefits of the design is that a state flow diagram can be generated
Exactly. I will also go for graphviz, generated from the tables, output only, run as a subprocess (I considered integrating it into my code, but rejected that alternative).
The problem with "blob&arrow" diagrams is that when your model grows into dozens of states, or even more, your diagram will look like a bowl of spaghetti. So I have introduced a tagging of states and events: Plot only states with tags x, y an z. Or: Collapse all states tagged Authenticate into a "superstate" drawn as one double-line blob. Or: Use style HeavyLines for states tagged HappyPath.
Large models is a problem even with tables. Look at e.g. X.215 (the OSI Session Service, X.215 Session service definition[^]): Where a set of states form a "superstate", with a set of "superevents" valid only for these states, the cross section is moved out of the main transition table and displayed as sub-table. I do this by enabling or hiding rows/cols by supergroup tags, so that you can e.g. work on connection establishment states/events only, and when that is done, hide these states/events completely or collapse into a single super-row/col. (I will use x.225 as the great trial for my framework - if it can handle X.215, then it can handle anything!).
I have (deliberately) put one heavy restriction on the action code: No blocking whatsoever! Any waiting, even for reading from a disk file, should be made as a request, and entering a waiting state. This obviously raises the number of states, and there must be ways to handle it. I also deny any access from other objects into the members of this entity (I use the term 'entity' for a table driven object, to distinguish it from an arbitrary object); it is a black box. All interaction is through events (which may carry value data). I guess many people would kill me for that; it is restrictive. But it gives you iron control over how the entity behaves and interacts.
Now I will sit down with my pet hobby project to bring it yet another step closer to completion. I really look forward to when I can start making real problem solutions in it!
|
|
|
|
|
We are are in wrong place for such discussions. But here is a thought for a debugging level, add GraphVis text syntax line to the log(s) and create a simple program to find those lines and generate a file. Then you can generate a state diagram from the file to see the path (or paths) that caused an exception/error to occur. Of course cross threading issues would effect the results, but that would just make the issue jump out at you.
Thanks for giving me some new ideas. I spent a lot of time in the past trying to come up with ways to make life easier. Including code to parse log files to find the relevant information. I miss the days when I designed and created everything for a small company. Back then, I went for years without someone actuality finding a software bug. In the corporate world, my first introduction to the code base usually results in me mumbling to myself, if not out wright cussing, due to the issues I see.
In the corporate world, it is almost not worth the effort to spend time improving the process. Because they tend to think in the short term and are confused as to the reason the product support team is working overtime. It is because they did not invest in the front end; do it right up front and maintenance becomes a trivial issue.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
IMHO, the so called "Online expert" don't have the clue what I do or what my constrains are with respect to time, price etc.
I work on the environment where each hours lost is money loss for my company. So My primary concern is that code needs to work. It doesn't has to look beautiful. Ugly is fine too as long as it works does the job within the defined parameter. "Looking good" is never one them.
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
You are right, it does not need to look beautiful. If you have worked with a code base for years, then finding the issue and providing a solution, in theory, should be straight forward and fiscally responsible. But if the company grabs a contractor off the street and expect them to do the same thing, under the same time constrains, then they are dreaming. Oh, they may come up with a solution that actually works, but 90% of them will be throwing in a patch at a particular point in the code, because they do not understand what the system, as a whole, is doing. That is how good code turns in to a confusing mess.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
I fix all (or most of the) errors / warnings which a static analysis tool like lint detects for my code.
|
|
|
|
|
What is the other option?
Fixing warnings by static analysis tools or the compiler has nothing to do with beautiful coding. It may involve standard compliance issues, which I always consider important. Errors will probably result in compiler errors, so those are a valid issue.
Always pay attention to [compiler] warnings, because you need to know why they were generated in the first place. Some of the warnings refer to legal code that does exactly what you want it to do, but does not fit best practices. Others are just BS - Example: The old 255 character limit on template parameters warning (MS VC/c++); this has nothing to do with whether the code is valid.
I once spent a great deal of time trying to eliminate some BS warnings, at the point of occurrence; only to learn that the IDE (whatever) had a flaw (bug) that would ignore my attempt to suppress the warning. Therefore, suppress (or comment in the code) any expected warnings at the location where they occur (compiler dependent) if you know the exact reason for the warning; otherwise any good programmer will be wasting their time looking at it. Never assume a warning is not valid.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
The word "expert" is bandied about rather loosely these days. Just yesterday I download code from an article at this site from someone who has posted dozens of them and they are almost always very highly rated. This article was also rated very well but the code was horrendous. Even worse than what I have seen in Q&A posts. Seeing something like that removes all pressure what so ever since what I do is considerably better than that. I actually had to spend a fair amount of time bringing it up to my standards.
"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?"
|
|
|
|
|
I know what you mean. I am not an MVP, but I have had to fix/rewrite published MVP code to bring is up to my standards. 
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
John R. Shaw wrote: up to my standards.
then you clearly are an expert. 
It's much easier to enjoy the favor of both friend and foe, and not give a damn who's who. -- Lon Milo DuQuette
|
|
|
|
|
some dictionary time:
first "Professional" - someone that gets paid for doing the job. Skill, knowledge (and connections) will dictate how much they get paid
Expert - a person who is very knowledgeable about or skilful in a particular area
- oh, so they could be "very knowledgeable" but just not good at implementing that knowledge.
It like any industry, once you start working with them, then you start to realise they just as fallible as you
|
|
|
|
|
I am just an average joe of the old school (still younger than many here), but I think the same as you. There are several very prolific authors where I facepalmed so hard several times...
I decided just to avoid whatever they write ever since... my head thanks me for that decission 
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.
|
|
|
|
|
then yes. 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
