I just transformed a sorting command that was seven lines long into an ungodly abomination that was about 70 lines.
We don't do these things because they are easy, we do them because we thought they are easy.

I will always remember that phrase and might never find out who came up with it.

it doesn't really matter if a code is 7 lines long if it's O(2^n). sometimes writing a better code means more lines

@darksideofyay does it really matter that it is O(2^n)? Sometimes maintainability is more important than performance.

@hjk101 it does matter if you're working with 100M entries... or do you think a code that takes centuries to run is maintainable?

@darksideofyay yes the code remains maintainable but it is than not the solution to the problem.
But saying it needs to be O(2^n) is premature optimisation if you just have to sort lets say pages of 30 entries. Depends on the situation not every solution needs to be scalable to data center size

@hjk101 it's not that hard to write a quick sort. "premature optimization" sounds like a stupid excuse not to prevent a shitty code. the truth is that when you don't care about this stuff, later you'll need the performance and then you have to go back and rewrite code you could've made right from the get go. you're using the kind of arguments I'd expect from management, not a dev. bad code is not maintainable, you're just creating problems for the future

@darksideofyay didn't ever have to implement qsort. It's a solved problem, practically available in every language.
I said maintainable code not shitty code.
Going to add a factor of 10 LoC as the OP states better have a good reason for the increased complexity.

I once had to work with a shitty dev that optimised the shit out of everything. Besides taking long to do simple things we had to debug lots of caching related issues and race conditions.
Yay negligible performance gain at the cost of hard to fix production problems.

That is something you can expect a dev to care about not a manager. Just as keeping stuff as simple as possible (but not simpler) should be a goal in everything you design. It's ok to sacrifice performance where it does not matter in favour of better architecture.

https://wiki.c2.com//...

@hjk101 there isn't less code in a qsort just because you didn't implement it. and just because a code is long doesn't mean the architecture is bad. in clean code for instance he recommends modulating the code in shorter functions and hiding stuff in factories, not getting rid of lines altogether. actually, he recommends being deliberately verbose to make the maintenance easier

Optimization should be always a risk calculation.

If an optimization has no relevance, e.g. the code not being performance sensitive, it is always a risk to change it - just don't do it.

If it is solving a performance issue, try to minimize collateral damage by only solving the performance issue and not sprinkling rainbows everywhere... (Aka fixing dozens of other things you just found out and want to fix now).

Optimizing or minimizing code just for the fun of it is dangerous and most of the time inefficient - as someone has at sometime to clean up the most likely regressions and possibly repair the collateral damage (e.g. repairing erroneous data)

Just because I read it here... Don't handroll existing algorithms if they are available in the standard library of your language... Use what exists there, unless for very good reasons.

The chance that you do sth. better than a team who specialized in it is not nonexistent (some standard libraries just suck) but pretty slim.

@darksideofyay from my perspective, yes there is. It's even provided and maintained by my OS.

I'm not saying you should optimize LoC either (said you should have a good reason for it if you expand it a factor 10, likely is not just making dense code readable but increases complexity).

Also like the rest you mention completely besides the point. The point is Premature optimisation and thus stating an optimisation goal without context is bad. Adding complexity how nice of an architecture you have because of that is still bad.

@IntrusionCM couldn't agree more

@IntrusionCM i think you misunderstood what i said. strictly speaking of algorithm implementation, not stuff that exists in a library, more lines != bad. the code still exists in a library, you're just not seeing it. also, the reason why we use libraries is because they're already optimized and not to redo code, not to spare lines of code, because again, the lines are still there.

on the subject of "optimization", that wasn't a word i used, because what i meant was writing a good code from the get go, and often that means writing more lines. also op is writing a sorting algo and I'm sure he has a reason for it, so I don't get the library derailing

@darksideofyay I think my comment had nothing to do with what you wrote.

My assumption was that the author had the joyful task to unwrap a chunk of shortened code that someone "optimized" or "mimalized".

Thus 7 lines became 70 lines.

So I agree with your first comment, less lines don't have to be better.

My comment regarding the optimization stems from the experience that some devs have the idea of less LoC = good stuck in their brain.... And suddenly a supposed simple change results in a patch of mayhem where stuff was rewritten to be "optimized" / "minimalized" just for the fun of it.

The reason I put optimized in quotation tags is that some devs really argument that shaving off a few nanoseconds on a task running less than a millisecond justifies regressions... Which isn't an optimization for me, as there will never be a measurable impact of said optimization for most software.

Thus my comment to please no, don't do this and don't see this as "good practice"… Don't change stuff that worked before just to shorten it.

Regarding the library usage: I never mentioned the word LoC in my comment I think.

I just said that handrolling algorithms, when they exist in the standard library, is a bad idea. For exactly the same reason you mentioned - the chance that someone does better than the team behind the standard library is pretty nonexistent. Has nothing to do at all with lines of code.

"It's not hard to write a quick sort", I misread the context there a bit.

It might not be hard - but usually the standard libraries have existing sorting algorithms which _should_ utilize the language internals and be optimized more heavily than a hand written sort algorithm can be. Thus my comment to not handroll algorithms, use what's given in the standard library and don't write it on your own.

Misread the context here a bit as I didn't connect it to the theta notation discussion before.