Everytime I read posts like this is like if people are arguing about the tiny details of the small picture, and it makes me sad.

Expecially because the big picture is easily stated: Write the least amount of clean code while providing value.

(PS: code is liability)

Code is both asset and liability; the asset is the feature set, while the liability has an interest payment in the form of maintenance.

The way you put it, you're optimizing for only one side of the books. The fact is that the value in a company is not in minimal clean code; it's in a recurring revenue stream, and ideally profits. Provide the most value with code which has low interest payments. Everything else being equal, smaller code has lower interest payments, but everything else isn't always equal. And depending on cash flow and market opportunity, maximizing value and to hell with minimal clean code - throwing money & devs at the problem - can make sense.

The distinction here is between code thats clear and concise or code that hacky and confusingly compact. Few people would recommend try and pack a 4-5 line function into a super complex and confusing one liner, but it is reasonable to put a 10k line class into a 20 line function. It's on us, as the developers, to make that tradeoff.

I think the spirit of the comment you replied to was closer to the "clear and concise" methodology rather than the "as short as is humanly possible" methodology.

Only the few people that don’t know anything about the map function or generator expressions and prefer messy imperative code where off by one errors are a given, if you want my opinion..

Less code less problems...

However in many cases, code is for; edge cases, input sanitization, type checking, null checking, graceful failure, logging... etc

Remember, [1] Docker can be implemented in a 100 LOC bash script, that doesn't mean it's a good implementation...

[1] https://news.ycombinator.com/item?id=9925896

At one job (porting a colossal legacy UI to Windows), I deleted thousands of LOC every day for months. Coworkers called me "the decoder." 25 years later I'm probably still net negative.

At one job, I wrote a moderately complicated Makefile (~200 lines) to build the company's product. Worked great.

After I left, I heard the company 10x programmer replaced it with 10KLOC of C++. (sigh)

This issue can easily be fixed by switching from delta LOC to the size of the git diff (number of lines changed). The big problem with this strategy is the huge difference between 10 lines of carefully engineered algorithm code and 10,000 lines of blah API calls and boilerplate. I can write API calls and boilerplate as fast as I can type.

> I can write API calls and boilerplate as fast as I can type.

I can write boilerplate much much faster than I can type, either I or the community have scripted that shit :D

I'm sure any shop that counted diff lines would ban editor boilerplate macros due to them being cheating. ;)

I would love to hear more details on this one

Not the GP but... Reduce a cross cutting concern from a system into an aspect and you get this easily.

I once worked on a product and identified an ability to eliminate 100K lines of poorly written, inconsistent tracing code into a robust ~250 line file using AspectJ. Management threw a sh-t fit and thought the risk was untenable.

AOP tools that effectively rewrite the app have incredible amounts of leverage. That can work to your benefit but it's also an enormous footgun if you get your aim wrong. It leverages up both cleverness and stupidity.

The risk of the new one or the risk of keeping the old 100K lines? Half serious question since I would estimate the risk of the latter to be much larger.

To me it sounds like he was introducing a hard dependency on AspectJ, which is as much a risk as any other dependency. I am guessing here, bit it is a scenario where a hissy fit from management has at least some justification.

How is a dependency on AspectJ any more of a liability than the dozens of other external dependencies in your typical application?

It is just as much of a liability, a priori neither more nor less. It needs to be evaluated like any other potential new dependency.

Plus, AspectJ is something that you have to be careful with. It injects code at the start or end of methods that can do arbitraty things and the method source code doesn't indicate that this is happening. So it has a great potential for code obfuscation.

Sort of unrelated rant. Maybe it’s because I’m not as well versed in Java idioms as I am with C# idioms, but using code that implements AOP using AspectJ seems much more obtuse than what I’ve done in C# just looking at the examples.

In C#, with the various frameworks - including on the API level with ASP.Net - you can use attributes to decorate the classes/methods with your aspects and it’s pretty easy to see what it’s doing.

You get the runtime binding basically by just using dependency injection as you always do.

C# dev here as well, but from a Java background. When I first moved to C# from Java one of the best AOP usages was transaction management. Database transaction management. You could write all of the code, whether it was dependent upon the db or not, and then decorate the methods with a transaction attribute. This decoration contained all the logic to get a db connection, begin a transaction, become part of an existing one, or create a new isolated one. Any unhandled exception caused the final unwinding to rollback any work that had been done in that transaction. So many try/catch/finally's avoided and so much boilerplate code.

I have yet to find any equivalent to this .NET world. Especially of you're using EF. Either you use ADO and have your try/catch/finally with manual transaction management, or you have the EF context which is just one big blob you hope succeeds at the end.

TransactionScope has been around forever in the .Net Franework version of EF.

It just came back to EF Core in 2.1

https://www.google.com/amp/s/codewala.net/2018/05/06/transac...

Yes, this is exactly the type of boilerplate I am talking about. All those usings and try/catch blocks which add needless code. It is possible to compose all of this into an aspect which then decorates your methods. Maybe I'm not being clear, so here is what I mean. Say you have a method that does some work, but calls some other thing to do some auditing. The auditing is nice, but it failing shouldn't halt the world.

  [Transaction]
  DoYourBusinessWork() { ...; AlsoAudit(); }

  [Transaction(RequiresNew, NoRollbackFor(AuditException)]
  AlsoAudit() { ... }

The TransactionScope is handled in the aspect. Commit/Rollback is all handled there is well. There are not usings or exception handlings within your methods unless you want to handle those specifically.

There should only be one using/try catch block on the highest level. All of the methods being called within that using block should just throw errors.

You could put the logic in attributes but I don’t consider a transaction a cross cutting concern. It would create a spooky action at a distance situation.

It's obviously highly dependent on the domain in which you work, but I would consider what you're saying to be a "business transaction" more than a "database transaction". If there is a 1:1 between the two then your way works. I tend to have situations where one business transaction is multiple database transactions. And the business transaction can succeed even if some of the underlying database transactions were to fail.

It was a C# file for an API that wrapped thousands of reports with a function call for each report, I moved to a design which was a single function for all reports.

I think what had happened is somebody had designed the file and everybody else followed suit patching stuff on - the entire codebase for that app was well below average. they had front end devs who didn’t know any JavaScript. In 2016. I lasted 6 months before I nope.png’d the fuck out.

It’s still not the worst application I’ve ever worked on though

Now it's 9980 lines less bad though :)

Not OP but also replaced a class. Very early in my career, I think I was 20, we were upgrading our Thrift version in a PHP/Java stack.

For some reason all calls were dog slow. Like minutes for simple pages.

Profiling revealed the class in question - and we were spending all our time in deserializing strings.

Copied the latest version of that class from the FB repo and luckily the interfaces were the same.

Worked for the next two years until we finally deprecated the PHP stuff.

Not the parent, but I once inherited a bunch of tools that used the same tracing function. Akin to dtrace. 6 people wrote 6 tools over different domains all with their own post-processing, filtering, formatting, etc...

It was a support nightmare, so we built a common library and collapsed the code base by 70%. Each tool was probably in the -8k eslocs range. Thankfully it wasnt c++.