6 ms·

Does anybody know where I can find a good, substantiated, critique of the common Java coding patterns, including on Android? This niche is such a huge mess that

Does anybody know where I can find a good, substantiated, critique of the common Java coding patterns, including on Android? This niche is such a huge mess that simply documenting all the bad things in a single codebase (along with explanation why they're bad) took me a month. It's tiring and mentally draining to do this: every other line of code you read makes you go "Why. Please, just tell me why anybody could ever think good code should look like this". Worse yet, there's hardly a discussion to be found about these things - it's "Uncle Bob" & co and the horde of their followers all the way, no dissenters. It looks like an echo chamber so hermetic that the most basic principles like DRY or YAGNI have a hard time penetrating it. What is the most painful for me with all this, other than it being 99% self-inflicted and not caused (you could argue it's encouraged by it, but the ultimate cause is the culture) by the language, is the fact that it has infected Kotlin code. Kotlin was built to increase expressive power of the language, doing away with multiple limitations of Java and offering lots of modern-ish features on top of it. The community looks split in half: the Kotlin community tries to get the most out of Kotlin, and the Android community that does anything in their power to make Kotlin back into Java, writing code as if the limitations were still in place and new features didn't exist. I know that the churn and "production readiness" of things on Android generally favors a more conservative approach, but it's still too much. I cry tears of blood every other code review I'm forced to do. If there's a single, definitive resource that I could point my coworkers to and eventually turn it into enforced guidelines, the author can count on a serious donation from me.

josephg 3y ago
Hah. I’ve spent several years writing javascript for a living. You can always tell when code was written by someone who’s arrived fresh from Java or C++. Their code is full of hundreds of lines of useless classes which can often be replaced by a few simple object literals. Unlike class instances, object literals can be easily json stringified and parsed, too! You can torture people who are like this in code review: “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kindergarten. I don’t know any good resources unfortunately. I feel like we need a “motherfuckingwebsite” equivalent for this - “just use a motherfucking function”. I want to link it to whoever insisted on adding a useless TextDecoder class in javascript that you have to instantiate, instead of just calling textDecode(…, “utf8”) using a global function like the rest of the standard library. I think part of the problem is that most people who hate enterprise java just learn a different language, set their resume on fire and start over somewhere better. That’s certainly what I did. I’m writing rust at the moment, and thankfully the lack of classes and distance from the JVM seems to keep most of this nonsense out. But having all the doubters leave makes the problem within the java ecosystem worse.
- polotics 3y ago
  Word! I just left a Java-only shop for pythonic pastures and the culture is so much more pragmatic and to-the-point. Hopefully soon enough ML models can be fed millions of line of code and produce the functionally equivalent thousands...
  - klibertp 3y ago
    They're trained on billions of lines of code - most of them are not very good. I'm using Copilot, and the docstring/docs it suggests are so bad it hurts. If left alone, Copilot would happily generate those thousands of lines instead of helping reduce them to hundreds. It's still useful if given enough direction, but you need to be really careful not to overuse it or risk getting mistaken for a junior straight out of a bootcamp during code review :)
    - tracker1 3y ago
      Yeah... I've noticed about half of what it comes up with needs tweaking... I really enjoyed it for SQL schema writing though... especially many-many table creation.
- raverbashing 3y ago
  > “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kindergarten. Lol true Don't forget all the getters and setters merely updating/reading a variable Python says "explicit is better than implicit" but Java goes too far with it, and in the most verbose/inflexible ways possible
  - Izkata 3y ago
    > Don't forget all the getters and setters merely updating/reading a variable > and in the most verbose/inflexible ways possible It's actually extra flexibility meant for two things: being able to override the getter/setter in a subclass, and keeping a consistent interface so users don't need to change how it's called if there was a refactor that adds something to the getter/setter (such as transforming the value because a different representation was more useful internally; particularly useful for libraries). Python has @property to maintain that interface if need be, but these Java conventions started when no such thing existed in the language. I haven't done Java in a long time, so I don't know if it has it even now..
Scubabear68 3y ago
I think a lot of it comes from the Spring framework. People saw those gigantic stack traces with all the crazy abstractions and huge names, and took it as the norm. It doesn’t have to be that way (see also Guice). But the Uncle Bob effect is sadly real.
- withinboredom 3y ago
  Some genius ported the Spring framework to PHP (and called it Symfony) and we have to live with the BS from Java world in PHP land. Anemic models and lots of indirection. What a sad world we live in.
  - cglace 3y ago
    Isn't laravel based on symphony components?
    - withinboredom 3y ago
      The Java infestation is real.
  - hyperman1 3y ago
    I did a lot of Java in the past, and ended up in PHP lately. Funny how PHP feels like 'I wanna be Java when I grow up', while Java (quarkus) says 'I dont wanna be Java anymore'. Then again,Java itself has Spring, starting out as '4 classes for an EJB is insane architecture overload' and ended up in dynamic injection architecture astronaut land.
_ea1k 3y ago
Those Kotlin issues are common when a lot of engineers from one language switch to another at the same time. We used to see the same thing with companies that had moved C engineers over to Java. Lots of weirdly overcomplicated C constructs. Meanwhile the newbs who only knew Java were writing FactoryFactoryFactoryImpls. :facepalm
stcroixx 3y ago
Don’t bother. Your preferred style will go out of fashion just like the previous ones all have. Chasing this is low value busy work.
- klibertp 3y ago
  > Chasing this is low value busy work. I disagree. We might understand what I meant by "style"[1] differently. As I think of it, it's comprised of things that have an actual, measurable impact on the effort required to develop the codebase(s) over time. It's not about tabs vs. spaces, snake_case vs. camelCase, or anything even remotely like that. I'm not trying to establish a company-wide set of guidelines for the sake of it - I believe that relatively minor things (in the scope of a single project) can lead to significant savings at the scale of tens of projects and five years of a maintenance window. As for the guidelines themselves: I don't care what they are, exactly, as long as a) they're there; b) they reduce said effort; and c) they're followed.
- josephg 3y ago
  The enterprise java programming style is worth avoiding because it’s a productivity killer. This style obscures your business logic, it makes debugging harder through needless indirection, and it creates pointless busywork from the need to write, maintain and document reams of unnecessary boilerplate. Foundationdb has official bindings in C, Python, go, Ruby and Java. The real bindings are in C, and all other languages’ bindings are well written, idiomatic wrappers around the same C library exposing the same functionality. The Java bindings need over twice as many lines of code as the Ruby and Python bindings to achieve the same thing. Even if this style of Java is only 10% less productive than that of idiomatic Kotlin, Go or Python, you will probably break even on the investment of migrating languages after mere months. I think that undersells it. The productivity difference is probably much higher. Especially for large projects. Improving your personal and teams long term productivity is just about the highest value work you can do.
  - deleted 3y ago
    [deleted]
  - 3y ago
phorkyas82 3y ago
Not a very recent one, but this "Kingdom of nouns" resonates deeply http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- deleted 3y ago
  [deleted]
ravenstine 3y ago
The problem with Uncle Bub is that his views only work in sync within very limited situations such as hobby coding and small projects by a handful of developers who are starting on the same page. A lot about Uncle Bub's teachings and FrAgile isn't practical in most of the real world besides a minority of outlier stories (and the problem with those stories is they don't track whether practices continue working long term). Take his views on "clean code" for instance. Or really any conception of "clean code." Clean code is bullshit. I guarantee you can take anything Uncle Bub or other notable programmers say about clean code, apply them to a tee at your job, and be told that your code isn't clean or "feels icky" by whomever joined the team before you did. No description of clean code that I've read has ever been truly helpful in my career. The only thing you can really do is decide what you think is clean code and for you and your team to reach a level of agreed disagreement so that everyone can get their job done. One person's descriptive variable name is another person's "that's too long I can't read with all these confusing names", and one person's set of short purposeful functions is another person's "I can't tell what's happening cuz I have to jump between all these functions." At the end of the day, you barely have time to write "clean code", because your boss wants features rolled out ASAP. Uncle Bub is also one of those guys who thinks good code doesn't need comments because it's self descriptive. This is one of the worst ideas to ever have met the software industry. No one's code is self descriptive. It's all a bunch of gobbledygook because it's meant to be run by a computer and just understandable enough for a human. It wouldn't kill us to just write some documenting comments detailing the intention behind code, but sadly most programmers either are too lazy or believe that if they need to add comments then that necessarily means their code smells. The result is that nobody knows anything about any given software project except for those who have been on the project the longest, and even they often don't know because... surprise... nobody wrote anything down! Just like with "clean code", it should be left up to teams how they want to add comments to code, and how much you comment your code shouldn't be influenced by memes from other programmers. Don't even get me started on FrAgile. It's just a way to dupe programmers into taking on more work and doing the job of middle management for them.
- tcfhgj 3y ago
  If you only write comments about intention, your code seems self descriptive, doesn't it? Why don't you write comments describing what the code does? > and even they often don't know because... surprise... nobody wrote anything down! Well, read the code

josephg 3y ago

Hah. I’ve spent several years writing javascript for a living. You can always tell when code was written by someone who’s arrived fresh from Java or C++. Their code is full of hundreds of lines of useless classes which can often be replaced by a few simple object literals. Unlike class instances, object literals can be easily json stringified and parsed, too! You can torture people who are like this in code review: “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kindergarten. I don’t know any good resources unfortunately. I feel like we need a “motherfuckingwebsite” equivalent for this - “just use a motherfucking function”. I want to link it to whoever insisted on adding a useless TextDecoder class in javascript that you have to instantiate, instead of just calling textDecode(…, “utf8”) using a global function like the rest of the standard library. I think part of the problem is that most people who hate enterprise java just learn a different language, set their resume on fire and start over somewhere better. That’s certainly what I did. I’m writing rust at the moment, and thankfully the lack of classes and distance from the JVM seems to keep most of this nonsense out. But having all the doubters leave makes the problem within the java ecosystem worse.

polotics 3y ago
Word! I just left a Java-only shop for pythonic pastures and the culture is so much more pragmatic and to-the-point. Hopefully soon enough ML models can be fed millions of line of code and produce the functionally equivalent thousands...
- klibertp 3y ago
  They're trained on billions of lines of code - most of them are not very good. I'm using Copilot, and the docstring/docs it suggests are so bad it hurts. If left alone, Copilot would happily generate those thousands of lines instead of helping reduce them to hundreds. It's still useful if given enough direction, but you need to be really careful not to overuse it or risk getting mistaken for a junior straight out of a bootcamp during code review :)
  - tracker1 3y ago
    Yeah... I've noticed about half of what it comes up with needs tweaking... I really enjoyed it for SQL schema writing though... especially many-many table creation.
raverbashing 3y ago
> “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kindergarten. Lol true Don't forget all the getters and setters merely updating/reading a variable Python says "explicit is better than implicit" but Java goes too far with it, and in the most verbose/inflexible ways possible
- Izkata 3y ago
  > Don't forget all the getters and setters merely updating/reading a variable > and in the most verbose/inflexible ways possible It's actually extra flexibility meant for two things: being able to override the getter/setter in a subclass, and keeping a consistent interface so users don't need to change how it's called if there was a refactor that adds something to the getter/setter (such as transforming the value because a different representation was more useful internally; particularly useful for libraries). Python has @property to maintain that interface if need be, but these Java conventions started when no such thing existed in the language. I haven't done Java in a long time, so I don't know if it has it even now..

Scubabear68 3y ago

I think a lot of it comes from the Spring framework. People saw those gigantic stack traces with all the crazy abstractions and huge names, and took it as the norm. It doesn’t have to be that way (see also Guice). But the Uncle Bob effect is sadly real.

withinboredom 3y ago
Some genius ported the Spring framework to PHP (and called it Symfony) and we have to live with the BS from Java world in PHP land. Anemic models and lots of indirection. What a sad world we live in.
- cglace 3y ago
  Isn't laravel based on symphony components?
  - withinboredom 3y ago
    The Java infestation is real.
- hyperman1 3y ago
  I did a lot of Java in the past, and ended up in PHP lately. Funny how PHP feels like 'I wanna be Java when I grow up', while Java (quarkus) says 'I dont wanna be Java anymore'. Then again,Java itself has Spring, starting out as '4 classes for an EJB is insane architecture overload' and ended up in dynamic injection architecture astronaut land.

_ea1k 3y ago

Those Kotlin issues are common when a lot of engineers from one language switch to another at the same time. We used to see the same thing with companies that had moved C engineers over to Java. Lots of weirdly overcomplicated C constructs. Meanwhile the newbs who only knew Java were writing FactoryFactoryFactoryImpls. :facepalm

stcroixx 3y ago

Don’t bother. Your preferred style will go out of fashion just like the previous ones all have. Chasing this is low value busy work.

klibertp 3y ago
> Chasing this is low value busy work. I disagree. We might understand what I meant by "style"[1] differently. As I think of it, it's comprised of things that have an actual, measurable impact on the effort required to develop the codebase(s) over time. It's not about tabs vs. spaces, snake_case vs. camelCase, or anything even remotely like that. I'm not trying to establish a company-wide set of guidelines for the sake of it - I believe that relatively minor things (in the scope of a single project) can lead to significant savings at the scale of tens of projects and five years of a maintenance window. As for the guidelines themselves: I don't care what they are, exactly, as long as a) they're there; b) they reduce said effort; and c) they're followed.
josephg 3y ago
The enterprise java programming style is worth avoiding because it’s a productivity killer. This style obscures your business logic, it makes debugging harder through needless indirection, and it creates pointless busywork from the need to write, maintain and document reams of unnecessary boilerplate. Foundationdb has official bindings in C, Python, go, Ruby and Java. The real bindings are in C, and all other languages’ bindings are well written, idiomatic wrappers around the same C library exposing the same functionality. The Java bindings need over twice as many lines of code as the Ruby and Python bindings to achieve the same thing. Even if this style of Java is only 10% less productive than that of idiomatic Kotlin, Go or Python, you will probably break even on the investment of migrating languages after mere months. I think that undersells it. The productivity difference is probably much higher. Especially for large projects. Improving your personal and teams long term productivity is just about the highest value work you can do.
- deleted 3y ago
  [deleted]
- 3y ago

phorkyas82 3y ago

Not a very recent one, but this "Kingdom of nouns" resonates deeply http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

deleted 3y ago
[deleted]

ravenstine 3y ago

The problem with Uncle Bub is that his views only work in sync within very limited situations such as hobby coding and small projects by a handful of developers who are starting on the same page. A lot about Uncle Bub's teachings and FrAgile isn't practical in most of the real world besides a minority of outlier stories (and the problem with those stories is they don't track whether practices continue working long term). Take his views on "clean code" for instance. Or really any conception of "clean code." Clean code is bullshit. I guarantee you can take anything Uncle Bub or other notable programmers say about clean code, apply them to a tee at your job, and be told that your code isn't clean or "feels icky" by whomever joined the team before you did. No description of clean code that I've read has ever been truly helpful in my career. The only thing you can really do is decide what you think is clean code and for you and your team to reach a level of agreed disagreement so that everyone can get their job done. One person's descriptive variable name is another person's "that's too long I can't read with all these confusing names", and one person's set of short purposeful functions is another person's "I can't tell what's happening cuz I have to jump between all these functions." At the end of the day, you barely have time to write "clean code", because your boss wants features rolled out ASAP. Uncle Bub is also one of those guys who thinks good code doesn't need comments because it's self descriptive. This is one of the worst ideas to ever have met the software industry. No one's code is self descriptive. It's all a bunch of gobbledygook because it's meant to be run by a computer and just understandable enough for a human. It wouldn't kill us to just write some documenting comments detailing the intention behind code, but sadly most programmers either are too lazy or believe that if they need to add comments then that necessarily means their code smells. The result is that nobody knows anything about any given software project except for those who have been on the project the longest, and even they often don't know because... surprise... nobody wrote anything down! Just like with "clean code", it should be left up to teams how they want to add comments to code, and how much you comment your code shouldn't be influenced by memes from other programmers. Don't even get me started on FrAgile. It's just a way to dupe programmers into taking on more work and doing the job of middle management for them.

tcfhgj 3y ago
If you only write comments about intention, your code seems self descriptive, doesn't it? Why don't you write comments describing what the code does? > and even they often don't know because... surprise... nobody wrote anything down! Well, read the code