Slashdot Mirror
The Best Ways To Simplify Your Code? (dice.com)
Nerval's Lobster writes: Technical debt arises for many reasons—whether moving goal posts, pressure to get code tested and released, high programmer turnover, and lack of documentation. Over time, it can also render code a spaghetti-like mess. But how to deal with it? In a new column on Dice, developer David Bolton offers some suggestions, ranging from refactoring to using compiler inference to increase readability and shorten declarations. While those techniques are straightforward, it's clear that a lot of developers let their code get out of control, and trying to plan beforehand doesn't necessarily prevent the work from getting overcomplicated. It seems like every developer has a go-to technique (or four) for keeping things a little more streamlined. What are yours?
Dice dice dice dice dice.. oh and add some dice.
Bye!
One line at a time.
.
And then there is always this old chestnut... The Big Ball of Mud.
It seems like every developer has a go-to technique (or four) for keeping things a little more streamlined. What are yours?
The mess is just part of coding. Deal with the mess. Accept the mess. Live with the mess. Join with the mess. Speak with the mess. Hear its answers whispered into your head. Nod assent as the mess intones its instructions. Welcome the mess in and let its tendrils throw through your veins. Understand the mess's greater plans and become its corporeal servant on this earth. Hail the mess. Hail the mess. All hail the mess. HAIL!
He's the sort of person who would sell the Red Cross to Dracula.
No really, do not do this unless you actually need to make changes in the area involved. Diving into old code just to tidy it up brings its own set of risks, and they may simply outweigh any 'niceness' advantage.
Instead - black box it. Interface it off. Make your new code structured, shiny and gleaming. Do black box-style testing (inputs vs outputs, almost like futzing) against the old code's API and make sure your interfaced version produces the same. Unit test the hell out of your new code.
Over time, should you actually find a genuine need to, you can then start to look at the black box. Can it be made into a series of smaller black boxes? Can you interface those off too, independently? Cool - do it, one at a time, and use the same approach you used before. Eventually you'll either be left with nicely restructured code or, more likely, nice code that changes often and gnarly horrible stuff that doesn't change ever, but that's hidden behind an interface/library/<insert abstraction methodology here> and works.
Should always weigh the operational risk of changing ugly-but-known-quantity against shiny-but-unknown-quantity. The path of what to do will be different for every case.
Ok... it's DICE but I'll bite... What I have found: IF time allows, the technical debt can be revisited and cleared/reduced. Some schedules don't allow for this, but during non-peak times (like the week between Christmas and New Years) when stuff is slow, I like to revisit some of the bad places and do damage control.
.02
I think spotting these issues, and giving the developer enough time to re-visit the bad section of the code is ESSENTIAL to maintain a relatively clean code base.
Code reviews can help, but the project deadline pressure-cooker usually prevails. My
The best way is likely by not reading a Dice article.
But seriously, the main problem is that many developers don't give a shit about the quality of their work and no one notices or does anything about it. It's not a matter of learning a technique.
If there's no rigor around what you write or how it gets tested, software will turn out shitty. If the development issues can't be fixed, it's often easier to just lie to the client or use hacks and workarounds to hide problems.
The fault for this lies with management. You need to police your developers but also treat them well enough that they're invested in writing good stuff. You need to hire good people and provide your mediocre developers with good examples to follow. If your developers think they're going to be fired long before they have to maintain anything, they'll probably turn the shittiness up to 11 out of spite. if they anticipate quitting over compensation or overwork or work-life balance, how good is their code going to be? If they hate your guts because they're on a visa and getting taken advantage of, how good is the code going to be?
It seems like every developer has a go-to technique (or four) for keeping things a little more streamlined. What are yours?
You get the job done as fast as possible and let the Indians worry about it when they get it.
See, you'll be on a project with an impossible deadline; all the while upper management has been wined and dined by the Tata/WiPro/CSC sales people and are gonna offshore the project for the production and maintenance phase. And many are just offshoring everything.
So, get your stuff done on time, learn everything you can and find another job. Because if you stick around, you'll be canned and when you are unemployed in this profession, you are unemployable - if you're any good, you'd have a job.
And do what you can to get into management before you're 35.
And if you're really smart, you won't fall for this STEM career hype.
i'm the smartest person on earth and have simple code
Are you sure you know what those terms mean? (e.g., Fast but simple solutions often create technical debt.)
When your question gets closed on Stack Overflow, then try to ask it on Slashdot?
Frankly, if your code is constantly getting out of control and becoming unreadable, you are not doing professional work, you are doing amateur work (and yes, I know that there are plenty of paid professionals who do amateur work. We've seen stories from Trend Micro programmers here recently on Slashdot).
It's not a set of rules to follow. If there were a mindless algorithm to follow, then a computer could do it. Instead, when you are about to write code, always ask yourself, "How can I write this in a way that future programmers can understand it?"
"First they came for the slanderers and i said nothing."
has a go-to technique
How did they know my technique!?
Understand the problem it addresses better.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Developer David Bolton has moved on from Dice and the remaining authors have been left scrambling trying to pull his notes and articles etc together to generate new content. They report having difficulty understanding how he cobbled together the disparate information into existing articles and have advocated just rewriting the articles from the ground up so they would be easier to maintain going forward.
Next!
Kidding aside, simplicity is the art in programming. It comes from understanding, not methodology. The question is similar to the one posed to Michelangelo: "How do you know what to cut away?" And the correct response is about as useful as Michelangelo's: "I just remove everything that doesn’t look like David."
Eliminate error handling.
Simplification of interfaces such as constructor arguments is a good place to start. For free functions be sure to give as minimal amount of params to Funktion in order that it can fulfill its purpose. Deciding whether to make a Funktion free or as an implementation Detail to the class or private to the class can also help to reduce the complexities of maintaining state. Make simple structures that do one thing well and then build more complex structures out of those simple ones.
Try to think of how you actually want to usw your classes and functions and design Them according to those goals. Limit the amount of oop in code since it forms too tight a coupling and the generalization usually fails anyway. Overall its just really basic simple things getting done right. These are just a few rambling ideas.
No one, absolutely no one, wants to read your shit articles. Stop pumping them into the feed.
nothing is simpler than no code at all
I just checked all the articles on the page (as of 11:10 am mountain time), and exactly one of them links to Dice.
Are all the other articles linking to sites that are owned by Dice?
I realize that Slashdot is owned by Dice, so the incentives are obvious, but right now I am not seeing a deluge of Dice articles.
Basically, I used to refactor constantly whenever I maintained code.
When sarbaynes oxley was passed, every change had to be approved by lower, then mid, then upper management in a series of 6 meetings. Doing anything except exactly the enhancement they wanted was virtually impossible. There is never a good cost/benefit for cleaning code when you think that way. Any change outside exactly what was approved would get you written up.
I went into management. Programming ceased to be engaging. it was easier to argue for code cleanup a couple times a year as a team lead than as a programmer because we had two people saying it would be beneficial.
But...
*Changing non-meaningful variable names
acnum to AccountingCustomerNumber
This was the number one way I helped other programmer's fix their bugs. I would just ask- what's this- okay rename it. what's that- okay rename it. And after a short time (20? 30?) minutes they would see the bug themselves. After comments like, "Why do I need a long name- we only use this variable a few times.
Refactoring any routine where the actual code was over a page in size into subroutines.
Running performance tools to locate "hot spots".
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Write it in the newest language you can find and put it in the cloud. It will take 10 lines of code to make the next hot must-have startup. Then sell it before people realize your code looks pretty but performs 40x faster when properly written in ugly C.
Don't get a development team larger than the task really calls for. I've seen so many chunks of code that really has not much to do be horribly convoluted because they split up the work amongst more developers than it makes sense to have working on it.
XML is like violence. If it doesn't solve the problem, use more.
It is in having detailed requirements and performing proper testing. Good requirements will lead to good tests which will detect most of code defects. Doing structural coverage will also find not needed code.
When I take shortcuts because I am in a hurry, I try to leave breadcrumbs. I put comments that start with the string "FIXME" and then write a quick sentence or two explaining how I would do it if I had more time. Then later, when I do have time, I can just grep for "FIXME" and find a list of things that need to be fixed. Those comments save me a lot of time, because I have an explanation from when it was still fresh in my mind, preventing many "WTF moments".
These books provide much better information on the topic and deserve a place on your shelf alongside the GoF's Design Patterns.
+4 insightful? Is everyone with moderation points 14 year old?
My first program:
Hell Segmentation fault
DHI Group Inc is owner of both Slashdot and Dice, making money on advertisement. So it's *you* who has to suck DHI's dick.
Do you think that lawyers sit around lamenting the complexity of the legal system that means cases take years and thousands of hours of work to decide? Or that accountants sit around wishing the tax code was simplified to the point where a regular small business owner could prepare their returns themselves?
It may be a good thing for humanity if programmers create less work for themselves, but it is certainly not a good thing for the programming profession in the money-go-round that is banker-capitalism. It is a stupid system, but I can't really see it being changed any time soon. Sometimes I imagine the accountants/lawyers who pretty much run the economy just have a big laugh at idealistic programmers trying to do 'good' in their jobs.
My advice is that if you want to write good code, go work for yourself, where you can profit directly from reducing the time it takes you to maintain your programs. Otherwise, my advice is work for a really big hourly rate and don't get conned by 'job security' and a foosball table.
Just stay away from Java and other bloated languages....
@mccalli perfect answer.
+4 Insightful
How about Programming Pearls and Beautiful Code?
One of the checks I do is to have a non-programmer just READ my code. If they can make any sense of it (Think variable and function names) then I continue. If not, I rewrite until it reads like English (with extra stuff in the middle :-)
I also have SHORT (as in a single line or perhaps two) comment block at the start of anything that isn't immediately obvious. This adds to readability.
I have code blocks that are more than 10 years old, that I still refer to and which I can make out the intent and the execution without issue because of these two very simple techniques. '$a' doesn't tell me anything. '$account_name' does. Stop trying to limit your typing load.
Other thing I do, which I find missing from a a great many things; Check your inputs and your return values. As much as this is Programming 101 level stuff, it is remarkably absent from so much code. How is it that SQL injection works at all?
Yes, Mr. Dice.com reputation manager.
+4 insightful? Is everyone with moderation points 14 year old?
Apparently, and it ignores the simple fact that Dice probably sucks small and medium dicks as well.
So, in keeping with the thread topic, I'll simplify the original statement: Dice.com sucks dicks.
It must have been something you assimilated. . . .
1. refactor
2. while you do that, divide up the code into modules that is a black box from outside
3. refactor those boxes as needed (split into more as needed)
and don't be afraid to do that before your program is finished, if it seems needed.
The time you save on a refactor is often quite a lot, so you shouldn't be too afraid of doing it.
Also making boxes like that helps testing.
But then again, I thought that was already what most projects did.
It's kind of a central point in most programming paradigms (both functional and object oriented).
I agree about code reviews: in fact I consider them essential in a team environment and wouldn't want to work in a code base where they will not be consistently held, at least going forward. Then the team can agree on some kind of standards and I recommend that the team develop a checklist for things the reviewer should check, where near the top of the list is: "Would I want to maintain this, and could I understand it easily if I came back to it years from now?". Also somewhere on the list is: "How was this tested?". Nothing ever gets into the master branch without such a review. Ideally the review is asynchronous, at least the first pass, to help see if the code is clear without its author explaining it.
Also, the coder should review his own code first with that in mind, before sending it to someone else to review.
Otherwise code becomes a mess. On a team small enough to enforce it, things can go much better.
A Free, fast personal organizer for touch typists: onemodel
Dice.com sucks big dicks.
it's DICE but I'll bite
It's the only way DICE will ever learn. :|
Dice.com sucks big dicks.
I'm guessing that Dice then is making someone or some people quite happy. A lot of guys seem to devote considerable effort towards getting their dicks sucked, so I don't really see how it's a bad thing
SJW n. One who posts facts.
If you're gonna suck dicks, GO BIG OR GO HOME
Dice.com went big, and OP was recognizing their bravery and determination.
Cheers, OP, I'm with you!
but during non-peak times (like the week between Christmas and New Years) when stuff is slow
Best week of the year because no one is there, and you can work on whatever you want.
"First they came for the slanderers and i said nothing."
Don't be clever. Most of us aren't paid to be clever. Follow the KISS principle. Be kind to the maintenance programmers and keep classes and methods short and to the point. After all the maintenance programmer might be you. Methods more than 1 screen in size are suspect. Avoid lasagna code.
Just a few rules I try to use.
putting the 'B' in LGBTQ+
Any principle that is good most of the time can be mis-applied. I have worked with developers who loved linq and would use it to compact loops and such down to a line or two of completely impenetrable gibberish. The long-term maintenance cost significantly outweighed the elegance of dearth.
I have also seen a simple multi-step script be broken out into a series of objects with an inheritance hierarchy...what was previously 50 some-odd lines of simple and straightforward code became 200 lines broken out over three files, with a slight reduction in performance (we tested it for that), and a bug was introduced in the process.
Whatever it is you plan to do...make sure you have a good reason for doing it, that whatever rules you are following actually make sense in your specific context, and that you have it all covered by good testing.
Just delete all white space and line feeds and your code will be much more stream lined. Removal of all comments will also significantly improve information density as well.
It's a feedback loop. Post stories in a manner that treats its readership like 14 years old, and we'll act 14 years old; which I'm fine with BTW cause being old sucks ass.
Life is not for the lazy.
Even big dicks won't go near dice, it's for little dicks.
Write it in assembly.
You should aggressively get rid of developers who 'make a mess' in order to 'get things done'. Such people are outwardly productive but are ultimately a negative for your project because you have to rewrite their garbage. Recognize them as early as possible.
> Make sure you understand the implications of every line you change (yeah, that's slow).
A complementary technique I used recently was to make sure I did NOT understand the code. I could understand the implications of changes, avoid any side-effects, by not trying to understand what the code did and instead applying mechanical transformations. I got a new job, working on a code base I'd never seen before. I made some significant improvements by refactoring code while making sure I didn't understand anything about what the code did. Basically, I saw something like this:
for (i=0; i = 1_000_000_000; i++) { ...
foo = 'bar';
fi = 'bee';
printf(foo, fi);
}
I could change that to this and know it was write, without understanding anything: ...
foo = 'bar';
fi = 'bee';
for (i=0; i = 1_000_000_000; i++) {
printf(foo, fi);
}
Similarly I could cut-paste blocks of code into functions, without caring what that block of code did - I only cared about which variables it accessed.
Or when I saw this:
cnm = get_customer_cumber()
I could then rename the variable via search and replace to cnm to customer_number throughout the scope. I don't know or care what a customer number is, but I know "cnm" means "customer_number", so I can do that search and replace.
So I'd say you can choose to either a) understand the code well or b) assume you don't understand it at all, and therefore make provably equivalent transformations, such as renaming, properly extracting functions and subroutines, etc. What's dangerous is when you make changes based on an imperfect understanding, when you -think_ you know what the code does, but you're wrong. You can go a long way while knowing that you don't understand it.
Or just write it correctly the first time? I know it may be harder and more time consuming, but you'll get further in your career if you do. If you work in Agile, add a task to do a code design if your not sure how to correctly architect it after thinking about it.
Then again adding unit testing doesn't simplify code, nor does using version control. One's for reducing # of bugs, the 2nd one is for change management and being able to roll back. 3/5 is what I'd rate Dice too.
Make your APIs sane, make ownership obvious and only abstract as far as strictly necessary. And for god's sake don't use PImpls - they might make headers cleaner but they make code twice as hard to maintain and debug.
I have developed, in 30 years of programming, to a much more radical position. Technical debt and mounting complexity are major problems, and I want to see a splinter movement within programming that defies the contemporary orthodoxy on how to solve these problems.
Object Oriented Programming is not a solution.
Refactoring is a failure as a solution. INSTEAD: We need to say "NO," from the get-go, to unnecessary technologies. Yes, refactoring is needed, but we've been talking about refactoring for decades now, and we still have so many problems. We need to say "NO" to new technologies, wholesale; To be much more skeptical and dubious of technologies. Don't import a whole system, when you're only really using only 1% of the technology in it. I see so many technologies in use in workplaces, where only 1% of the functionality is needed. (I'm looking at you, Celery.) These massive systems have security flaws, bugs, and inflexibilities, that require custom patching and regular necessary upgrading and updating. They are built on top of other massive systems that have security flaws, bugs, and also require patching and updating. Yet because of "We don't want to implement something that someone else has already implemented better, and actively maintains for us," I see decisions made to get the huge big massive honking thing that ** isn't actually needed. **
When you have 10,000s of lines of glue code, to glue your systems together, and you're actively maintaining them against one another, ... and the alternative was to write a 500 line program that would do EXACTLY what you want, and is easy to modify and understand, ... ... something has gone horribly, horribly wrong.
When you're sending massive REST calls in series, with HTTP headers and payloads and everythings, ... ...when a single maintained TCP stream would do just fine, sending 4-byte packets back and forth, ... ... something has gone horribly, horribly wrong.
I said above that Object Oriented programming is not the solution. I maintain that. I think we need to seriously re-evaluate what the heck we're doing. I propose that we look at the notations we are using in writing programs. Forth has a radically different notation. APL has a radically different notation. There is great expressive power in these systems. They are compact and powerful. I have come to see that smallness is a great virtue -- not baroqueness.
A great **design** can make a dramatically smaller technology footprint. We're so focused on agile methods, that we don't see that a design can have a dramatic minimizing power. It's not about waterfall. Designs can be iterated after all. If the design has a small footprint, modification is quick and easy. The entire program can be rewritten in a reasonable time, if the design is little.
I am not writing this to convince anybody. Rather, I am writing this so that fellow programmers who resonate with what I'm saying are encouraged. These ideas are very much in the minority, and are drowned out by the mainstream orthodoxy of programming. But I believe that serious programmers who have been looking at what is going on can recognize what I'm saying here. I would like to see more expression of challenge to the orthodoxy here.
My Pointers for more information, for the interested:
* http://suckless.org/philosophy
* deep study of Chuck Moore's ideas on programming
* http://www.colorforth.com/1per...
* Alan Kay's ideas on programming
* the design of the TempleOS, which is extraordinary and powerful while minimal
* "Software Survivalism" and "Neo-Retro Computing" (Sam Falvo)
Make your code funny. Compilers make the same binary size whether your variables are one letter or a whole sentence long. Tell jokes, rag on your boss and co-workers (nicely!), make error messages a hilarious variable with the serious message inside. The best place is when you output a message to the user and need them to hit a key before you continue. Most languages need a variable as part of the input statement, but you'll never reference that variable again. It's perfect for snide remarks that only other coders will see. My favorite tho is when I once wrote
Open(the.pod.bay.doors.Hal) else print Im.SorryDave.I.cant.do.that
with properly assigned values. It compiled & ran fine, but wow did it get a good laugh from a nearby cubicle a few months later. It livens up the workday and you'll be thanked for it.
On the one hand you take life too seriously, and on the other, you do not take playful existence seriously enough. Seth
Dice hangs out a truck stop glory holes.
When you fix "works" you normally get "broken". Better is the enemy of good enough and if it aint broke don't fix it.
Taking a little longer to do the job right first time is a great idea, but if the boss is a micromanager who wants everything done yesterday it just will not happen that way. The only way in this case is to leave yourself clues to ease the pain when the next disaster hits.
I'm being a little unfair though: most bosses are actually not that bad (though micromanaging imbeciles do exist). However what most bosses do not understand, in my experience, is the value of *thinking* about how to write the code. Not brainstorming, not googling like a million demented monkeys hammering on a million typewriters, but stopping for a brief time, staring blankly into space and just thinking about "how can I do this right?". This sort of introspection is the best way to write good code first time, and it's also almost guaranteed to get the boss on your back asking why you're not working and making inane suggestions about talking to golden boy two desks over.
What you suggest is the right way to do it, but it depends on having time allocated to doing it the right way and a manager who gives a crap about anything but squeezing out more features faster.
Otherwise, you become just that guy who never meets the deadline. Shortly after, you become the former occupant of cube 230B.
.. as much as some companies incentive code addition. If a programmer is paid using a metric of LoC then, I think, something is wrong. There is just as much work done in removing code as there is in adding it.
The flipside is important, too, though: Just rewriting good eloquent code with "clever" oneliners is absolutely wrong.
Code that has to be there should be eloquent and well-documented. Code that does not need to be there should be removed.
remove nospam. to email!
4 out of 5 of his suggestions were so simple the you could have gotten them out of any of the 10,000 blogs on 'improve' your programming, Refactor, use OOP, Unit Test and use Version Control. Any programmer that has more than an ounce of experience is already doing this.
The fifth suggestion was the one that was just plain stupid. Using auto/var for declaring variables is the intellectual equivalent to Visual Basic's, Option Explicit Off. Sure you could do it but why?
I'm going to repeat a comment in that article because it's the single biggest thing that helped me:
Clean Code by Robert C. Martin
http://www.amazon.com/gp/product/0132350882?pldnSite=1
There is also a course on PluralSight for this is you have access to it.
Dice is getting a lot of crap, and I couldn't agree more.
Second. Someone mentioned "Code Complete". A wonderful suggestion. Data Insights is a wonderful book on data visualization that helps imagine code and data in different ways, which helps with the logical organization.
To add more though, from a managerial/leadership level perspective on how to create better coders and thus code (as a hands coder/manager):
1) Have your developers develop with the 80/20 rule. That is: 80% of development is analysis, design and research and 20% is implementation and testing.
2) Refactor as a regular practice? Screw this. This is a lesson in insanity. Literally. Leverage SCRUM and Agile regularly to detect and and shift coders off responsibilities they may be obsessing about with refactoring. A good rule of thumb is: a coder who's spending too much time refactoring is a bored coder.
3) If creating a product, always version, and always move forward. Once done with a version, hire outsiders from other cultures and backgrounds to create new versions of your product and kick back and watch them from the sidelines until they do something cool and new you never thought of before, then come back and redevelop from the ground up implementing both the lessons learned and new concepts and ideas.
4) Create artificial bottlenecks. Seems contrary to logic, but one of the most interesting things I have learned as a leader has been to intentionally silo certain processes - such as nightly builds - to reinforce tighter code. This reinforces better communication and an awareness of code quality when implementing.
5) Formalize code change approval paths and QA processes, and leveraging indirect communication tools such as Bugzilla for communication with QA staff and/or customers. When coders become accountable for their code publicly, they tend to code more reliably.
Now how does this all work to simplify code?
Pretty simple. Environmental stimulus for you as a coder is far more profound than most coders are aware of. Put you in a closet and you'll start thinking in one and your code will reflect that. Put you as a male around gorgeous women in a call center, and your code will come across distracted but magically will work extremely well for the call center people employees.
Most coders aren't aware there's no silver bullet for perfect development and there's no such thing as perfect code. I've been there, and fallen into the game of how many lines can you code this in with coworkers, all to find my reduced code was complete unreadable afterwards and I was screwed if I wanted to make changes to it later..
For instance, normalization for databases works well, for instance, but there's places you don't want to use it, and other points where you can over normalize and make your data unworkable. The same thing is true for source code, whether that's SQL, C#, C++, Visual Basic, or PHP with Javascript, and whether its embedded system development, or it's an application or a web UI.
So as a manager and leader, what becomes more important is keeping my coders happy and balancing that with creating an environment to optimize their coding for the customer(s), whether that's a shareholder, the person who's purchasing the product, or the wealthy investor who will buy my company in 2 years.
As a coder yourself. You become a great coder to work with when you actually start working with the manager and leader and can understand why they're making the decisions they are and help them along.
The best way to simplify your code though?
Simplify your environment. Align your environment with the goals you wish to code for. Immerse yourself. ... and go....
The rest will fall in place.
Or just write it correctly the first time? I know it may be harder and more time consuming, but you'll get further in your career if you do.
Depends, in R&D I write an awful lot of throwaway code - maybe as much as 80% (depending...) but, at the outset, I can't tell you which 20% will be kept and used in the product and which 80% ends up being "investigatory."
Sure, you could just rewrite the 20% from scratch and "do it right," but that's not as efficient as reusing the proven test mules - which usually aren't in too bad of shape, if you trim off the FIXME: and TODO:s.
In my career, being able to show working code, quickly and easily, is important - much more concrete than sitting in a meeting and drawing bad sketches on a whiteboard while waving hands and attempting to explain things to people who all visualize verbal explanations differently.
Horrible advice. There are times you need to aggressively hide the implementation of classes. Lookupup tables (maps) are a good example. Give such components special treatment if they are widely used and have a stable interface. If you unit test, and you should, on platform debugging should be rare.
Once I can't bear to look at my old code any longer, I don't even feel like investing the time in trying to bring it up to snuff. I just rewrite it, which usually works out well because I get more experienced over time and have thought of different approaches that could have been used originally. Fortunately I'm almost always the sole author and I deal mainly with embedded apps, so the code is fairly short. I'd never dare to use this approach with more complex programs, assuming I could even talk anyone into letting me.
Best thing I think, which will never happen, is to keep the work load light so that the team has actual time to spend making the code better in the first place as well as time to go back and rewrite older code. But too often everyone's on a death march to meet deadlines, you can only add features and fix bugs and any redesign or rewriting isn't assumed to help the bottom line. A lot of bad code I see is not because the programmer is bad but because they're being forced to add the code quickly and move on to the next task quickly.
When I want to refactor code, I first make sure we're working in a programming language that is suited for refactoring. That usually means it must be Java... nothing comes close in refactorability. It certainly rules out anything that isn't extensively checked by a compiler (eg. Javascript) -- there's always code paths that aren't covered in tests, and you rely on the compiler to warn you of potential problems in those.
Second, I make sure there are good tests available, not just unit tests but also integration tests. This is usually the case on projects I work on, or I won't be sticking around for long.
Third, I do refactors in tiny incremental steps. Usually it's like "remove one method", "remove a parameter", "add/remove an interface", "delete a class", "split a class", "move a method", "make a parameter required by moving it to a constructor", "make something immutable by removing its setter".
As soon as you do one of those, there are gonna be errors detected by the compiler. I ignore the ones in tests and quickly check the ones in real code to see if the refactoring does not have something I did not foresee that would be tough to fix. If there's something unforeseen, I think about what refactoring would be need to be done before this one that would make that easier to fix later.
Once it looks like it will work, I fix the errors in one class, then in its test, then run the test to see if nothing broke. Then I go to next class, until all the errors are gone (usually this takes around an hour for 50-200 errors when I started).
I then run all the tests, and if everything is ok, I make a commit of that refactor step. Then I start with the next incremental refactor step. At any time, I can merge the stuff with master and stop and work on something else, while still having some small benefits of the refactorings done so far.
In this fashion I've refactored existing code bases to use a different time/date system, refactored code to use two different models (instead of a unified one), made models slowly immutable (it's amazing how many problems you discover when you start doing that), etcetera.
If you are in a competitive production coding environment where there are eight or more people in the team doing the same similar sort of work, then the person that takes the longest to complete tasks and completes the fewest tasks is the one that gets "churned". So in that environment those that design-and-think lose out to those that copy-and-paste. The optimization would set as a separate task for the optimization engineer.
That's different from an R&D environment where your job is to find the most efficient algorithm to do something.
Quit.
Find a new job and new code. Hopefully the debt will be less.
Implement first, optimize later! Don't pre-optimize, because optimization usually introduces code complexity. A lot of the time your code will be "fast enough" or "small enough" to get the job done. Don't get too clever. Also, plan things out at least a little bit. Don't just start coding. Draw some pictures, talk through some use cases... try and ferret out and plan for some oddball corner cases before your testing finds them.
"False hope is why we'll never run out of natural resources!" - Lewis Black
YOU WIN THE INTERNETS. That is all.
Seriously, funniest thing I have seen in days!
What you suggest is the right way to do it
It is almost never the right way to do it. Specs change, or are incomplete, or don't even exist. So it is better to hack up something quick, make sure it is what the customer (or your boss) actually wanted, and then go back and do it "right". It is silly to waste time making code "perfect" when it most likely will be thrown out.
Take it away and make it yours.
I could care less about fixing or polishing work's code. They'll just toss me away in 2 seconds if it suits them.
My own code however, I sometimes hack on for days without adding anything. Purely cleaning and making things logical, it's actually a time sink of mine. Why? Because I can't talk smack about work's code if I don't actually have something I could point to that *I* wrote in what I consider this "better way".
So I have a rather huge personal C++ project that does everything from parsing webpages, reading email, listening to music, scratch pad, IM client, IRC client, and Video player. Client/Server of course and using otl, libvlc, protobuf + openssl for AES. OpenGL rendering and custom widget sets... Why? Because I'm bored and enjoy the idea of only using my own code (minus the compiler, linker, build system). You also learn a lot and get to see what real productivity is by not having any red tape. Without such a project, I may have accidentally put that time into some stupid work project that I'd have forgotten about by now.
Cliffnotes: Unless it's my code, I really could care less in a metrics-focused programming job. You can't quantify aimless cleanup work, thus you only get ticket work out of people. It's quite simple.
Dice hate aside, it really is a pretty lame click-bait article that could have been written by a bot. It's not bad to spark a discussion on Slashdot though so I'll bite. The first thing that comes to mind is DRY. Knowing when you are RY isn't always easy though, and there are some interesting tools out there that claim to be capable of detecting patterns via static analysis. I have to confess I haven't used them though. I'm wondering how big an obstacle to reduction is found in the "prestige" of "managing millions of lines of code". If somebody came along, audited it, and told them it was really just a massive macro expansion that came from 2500 lines, they might not be so happy.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
That also depends on management. If the management is any good, they'll make it clear when a spec should be treated as final or tentative. They'll also give you time to do go back and re-do it right if/when it becomes final.
Otherwise, you have no idea if it is fixed or not and you will NOT get a chance to replace the spit and baling wire later.
"Tis a fine barn, but is no pool," Early Simpsons. Does you thing really need a blah--just because everyone else is doing it. Do we really need a internet connection for a notepad application? How much work is the "Managers" and now, the "Centers" doing?
Just don't put useless crap no one needs in your software.
https://www.youtube.com/c/BrendaEM
Change jobs!
"What you suggest is the right way to do it, but it depends on having time allocated to doing it the right way and a manager who gives a crap"
On one hand, you already have been told that's not usually "the right way to do it" since allowing for features to go along and see, once they are tested in real world, which ones will stay and which ones will not is usually the best way to go.
On the other hand, unless your manager is both a micromanager *and* technically competent, don't think about what your manager can do for you but what can you do for your manager.
If you think a bit about it, he's completely at your mercy and the code can not be "done" till you make it "done". No, not when you *say* it's done, but when you *make* it done: don't think about refactoring the code and refactor the way you write it instead, and even if your manager is the kind of "you say it's a mock up, but it looks good enough for production to me", if there's no box, no screen, no output, it won't be done even for him. Instead of coding "the happy path" first and then go after the corner cases (and never have time for the corner cases), go with the inner parts first and make your code so it doesn't do anything useful till you deem it good enough (and don't fool yourself: it's probably "good enough" quite before you usually think).
I think one good way is to just write ugly code quickly. Then delete it and rewrite it. And repeat until you think rewrite does not help. This works best when touching unknown code. With your own code you can thinl it in your head.
Each time you rewrite a function in a different way the inherent risk of bugs increases. As such, you'd want to undergo all the sdlc retesting, which does add overhead...
The most effective single step towards simpler, easier to understand code is to not use any form of object-oriented programming. It generates an enormous amount of bloat and it creates heaps of problems of the very type it was once said to prevent.
Use Sonar or other code checkers.
After you resolve the critical things (i.e. circular dependencies) etc there, life will be simpler.
Since your code is shorter, other people can read and understand it easier
Assuming a simple null = 0 check: object obj = 123; int somenum;
Short: somenum = obj is int ? (int)obj : 0;
Long: if (obj is int) somenum = (int)obj; else somenum = 0;
I would argue the Long one is easier to read.
Short does not mean try to condense it... you can stick everything on one line to achieve that and it will be the most illegible and hard to read format.
Ternary conditions are not a way to make your code short, you should consider them equal in length conceptually but more concise - that can be good or bad depending on the complexity of the statement.
That's not to say there is no value in trying to keep some things concise for legibility, but there is a difficult balance between terse and concise when doing this... I think the important thing is to focus on clarity, this other attributes are just ways to achieve that, they should not be used for their own sake:
Short, concise, simple (as possible) and DRY can help achieve clarity; using single letter variables and ternary statements for everything will achieve a short terse and unclear mess.
And this is the nice reason what is wrong with simplification of code is not as easy as it seems.
You did no verification of the statements and by changing the code, it could well be that it is wrong now or in the future. You do not just change statements with the assumption it will be ok.
The next shortening would be Dice.com sucks. And then just Dice.com (as people would be thinking the sucking would be implied.) So we went from an insulting "Dice.com sucks big dicks" to the advertising sounding "Dice.com" and all this because of beautification.
Don't fight for your country, if your country does not fight for you.
Judging from the way most programmers "refactor", the solution to complex code is to replace it with even more complex code, because something that employs as many technologies, buzzwords and frameworks-of-the-week is obviously better.
Identify Object Inheritance, Encapsulate Behavior for a Polymorphic State.
Here's a worksheet: http://i.imgur.com/0RnAzbj.jpg
Here's a video: https://www.youtube.com/watch?...