How do I stop my program code from quickly becoming a clusterfuck of a design?
It always starts out simple and clean but ends up unmanageable with stray hardcoded hotfixes .
you need to be able to see more abstract patterns when you need to hardcode a fix. also a "hotfix" means a fix you introduce without swapping out the code/component, and something tells me you think it means something else.
>>54010084
No idea. I just start making a clusterfuck and along the way better and more ideal design patterns just come to me when writing code.
>>54010084
Program more.
You have not yet reached the zen of programming.
>>54010084
I usually start coding, it ends up as a clusterfuck, but I continue until I have the feeling I covered the whole functionality of the code, no matter how fucked up and slow the code is. This progress makes me understand what the code needs to do and how to organise it appropriately.
Then I just start over, often reusing many snippets from the old code. The resulting code is usually half the length and twice as fast.
I used to waste a lot of time planning projects before I start, but usually I still have to go through the same process of making a code draft and then starting over.
its called MVC you fuck
>>54010084
Thoroughly plan out your algorithms. If you find a bug that needs a hard coded fix, you need to rethink and prove your algorithms correctness because it's probably wrong
>>54010084
you need to refactor as you go, read this...
Refactoring. Improving the Design of Existing Code. by Martin Fowler.
Over enough time it is unavoidable. You can only break logic up in to different functions and different files for so long until some aspect of that attempted organization becomes unmanageable.
>>54010084
git gud?
>>54010084
write lots of functions, methods, subroutines (depending on your language)
have some idea where you want to end up before you start.
you don't want a rigid immutable plan or anything, stuff will change as the program comes together, but you don't wanna just sit down and write code without spending some time thinking how the program should fit together. clusterfucks happen when you work around shit as you happen to find it instead of thinking a bit ahead, in my experience.
also this >>54012135. you'll make mistakes in your plan and see that something you did should've been done a different way. At that point, stop and fix that before you start adding more stuff. Pay off your technical debt before you spend anymore.
>>54010394
same as this. i write out specs and drawings on a whiteboard if there's too many things to consider at once. it goes like this for anything non-trivial:
1. write the problem i have in plain english
2. start replacing the english with comments of algorithims or data structures
3. start replacing the comments with real code
4. tweak the code with logging statements
5. test the new code
at any stage there's the possibility of having to throw away everything or go back a few steps. and i don't add fucking hotfixes to flawed design.
>>54012330
this is simply not true, you refactor the code as you go, instead of gradually degrading the software gradually improves.
use a safer language that doesn't reward you for writing bad code
>>54010084
If you're talking about HTML and CSS design, there's no way out of the clusterfuck.
Just make sure to comment everything so keep in control of things.
>>54012677
>If you're talking about HTML and CSS design
he said programming.
>>54010084
Don't rush it. While a hotfix might allow you to quickly see if a deeper functionality is working well, once you see that it is working, backtrack and fix the shit you pulled off to get there. Always make sure your back is clean before proceeding forward. Otherwise after a while it's as if you are building a roof on a stone house where one of the walls is in dirt because you were too in a hurry to go fetch more stones at the quarry and wanted to begin the roof right away.
>>54012690
the same advice also applies to javascript
MVC framework, auto syntax checking, git validation, test-first, purely functional (no side effects), continuous integration.
>>54012771
by syntax checking I meant linting
>>54012771
i agree with this with one provisio, MVC is not always appropriate, its a pattern that has its uses but you shouldnt try to shoehorn it in everywhere.
>>54012951
some architectural structure should be used
>>54012969
certainly! no quibble there.
>>54010084
Switch to pooing in a loo, not on the streets.
>>54013034
ayyyyyy
This is the reason I want to go into QA instead of development. QA won't be a clusterfuck, will it? I mean, how could it be when you're just testing outputs automated or manually?
>>54013975
oh my sweet summer child, you're about to learn how bad and arrogant software developers can be
>>54013975
>QA won't be a clusterfuck, will it?
>>54010084
THIS IS A HEADER.
this is a header.
I do it like this:
>write shit code that works
>refactor it into something nice
>repeat
This is from a brainlet, so my method may only help if you have ADD like me
Anyways, when I code, I actually have to draw shit out by hand first, like a flowchart or something, and then when I write the actual code I have to leave myself comments so I don't forget what something does
I even have a to-do list in the very top of the page of my code otherwise I forget what I'm supposed to do
Objectify simply and elegantly.
Make sure your method and variable identifiers are coherent.bedroomClock.setMinuteHand(43);not
object3.min(43);
>>54012771
Any other answer is wrong or a technique that works only for the individual writing. These are the right tools for the job.
>>54013975
qa: hi dev i've found a bug
dev: wut?
qa: i've found a bug, see!
d: works on my machine
q: well it doesnt on mine
d: you must have installed it wrong
q: nope i used the installer
d: where didja get the installer
q: over there
d: yeah thats the old one
and so on.
Get rid of magic numbers by naming your constants so it's easier to edit your code
>>54012649
In the wild you don't get that much time to refactor. It isn't some silver bullet. Future you isn't significantly smarter than current you and future you lacks the exact context you had when you wrote it the first time.
>>54015824
>In the wild you don't get that much time to refactor.
yeah i dont take those jobs anymore so in my "wild" you do get time.
its actually a good question to ask at a job interview "do you allow for refactoring?" weeds out the crap jobs.
>It isn't some silver bullet.
never said it was, it does however give you a hope in hell.
it does mean that over time the code improves rather than turning to shit.
>Future you isn't significantly smarter than current you
>and future you lacks the exact context you had when you wrote it the first time
that context is stored in the tests you wrote when you first wrote the code (you did do that right?), you're changing the code now, so make the change now, make the tests pass now and refactor now.
inb4 but the code i want to change doesnt have any tests! so in that case write a test for what it does now, write a test for what you want it to do, make your change, make sure all tests pass, refactor if needed and you're good to go.
>>54010084
You need rules anon.
>>54010084
Like some have said, use functions and classes. Put them in separate files then import/include into the main code.
Navigate using "go to anything" of something like it.
Just rethink your data structure.
Git Gud
Plan out your program before writing it.
First thing I do is grab some paper and outline the basic structure of the program I'm writing, with an emphasis on modularity.
>>54010084
Comment everything in plain english as you write shit.
>>54010084
Bounce ideas off of others. having one lead and a few supports allows multiple views to make thing better with the lead to keep the direction forward.
Also break it down into a general flow chart or other organization setup, if you can see all the major steps needed it helps organize the structure. Do this before you start coding. Plan twice, code once.
>>54010084
Identify code smells.
Refactor.
Repeat.
make shit as simple as possible
abstract when you know how shit's gonna change
duplicate code when in doubt about whether abstracting is absolutely necessary
keep shit as stateless as possible but don't force stateful problems into a stateless paradigm
keep your public apis simple and nice to use
choose great defaults
learn your langs abstraction capabilities and use whatever fits the problem while still staying simple
use names that are neither too long nor too short for the given context
>>54014519
This is fairly accurate, actually.
Bugs generally don't exist unless you can prove to the development team that they do, and they can instantly duplicate it in their environment.
Bizarrely, when it comes to software dev and bugs the software is presumed innocent unless proven guilty.
>>54010084
Don't make stray hardcoded hotfixes, fix each problem properly. Consider what it is about your program causes the errant behavior to fail and fix it.
>>54010084
Make your program out of comments before you fill in the code. Start with the broad view of what it does, break it down into steps, break each step into what it does, break that down into steps, and so on.
>>54012771
I find continuous integration has made me sloppy, more likely to throw out hacky shit until it works rather than making everything as neat as possible before the next push.
It is handy for testing tho
>>54014193
This:
The easiest way to tell between students or hobby programmers and people that work for a living is their views on code 'verbosity'.
Any opinion that claims something like "Java is shit, it's too verbose" can be immediately discarded by those with common sense and actual experience; because Java is pretty much purpose built to avoid an unintelligible mess of code situation like OP is describing.
OOP, and name your methods and classes intuitively to help follow the program. Having to pick up some self proclaimed wizards 6500 lines of bullshit, poorly named and commented code turns a three day task into a three week (or more) task.
>>54019415
It's funny. When programmers work and look at their own code they know it's a buggy, hacky, fucky mess and are always ashamed of it. But the instant someone else points it out it's suddenly perfect and flawless.
