• bvs23bkv33 (unregistered)

    does not indentifiers differ only in frist 31 characters?

  • Ex-Medical developer (unregistered)

    Beats the longest I have seen at 82 characters which was written by supposedly the companies best developer which was:

    MedicationsWithZeroQuantityOnPrescriptionsNotOfRecordForNotesValidationRuleFactory

  • Hasseman (unregistered) in reply to bvs23bkv33

    At least it was like that for an Pascal dialect for CP/M long time ago. Did debug this for a fellow programmer back in the 80th

  • Random Guy (unregistered) in reply to bvs23bkv33

    C99 bumped to 63 letters. Not checked later standards.

  • TruePony (unregistered)

    My belief is that longer method names are fine when they increase clarity. This? This does not increase clarity.

  • Zach (unregistered)

    Who says longer isn't better? Where I am we have functions that easily exceed 4000 lines (it's fun debugging :) )

  • (nodebb)

    So... I expect Spring to make functions like "And/Or (Not) TitleIgnoreCase", "Flags Null/NotNull" etc.. And that for multiple variables.

    So that's a lot of redundant code. Still I'm wondering, how would this be easier then having one function (handwritten) with multiple input parameters?

    But... as long as it works... right? :#

  • (nodebb)

    TRWTF is Spring and its method name to SQL conversion. Dear Java programmers, come to .net where LINQ solves this beautifully.

  • (nodebb)

    Is it just me or is everyone seeing the navbar overlapping the top half of the article title? I frist noticed this about a week ago.

  • Lorens (unregistered)

    What is a notorious? I think I might want one.

  • (nodebb)

    The more I think about it, the more horrible it seems to be. Who in their right mind decided to say, let's put a subset of a programming language inside a method name? Unbelievable. I don't think even PHP has this level of craziness.

    Dear Java programmers, even if you don't run screaming into .NET after this, please please don't ever use this abomination. Not even once, not for any reason. Never.

    Addendum 2018-10-22 14:51: *Abomination of an ORM feature.

  • (nodebb)

    THAT'S NOT HOW SELF-DOCUMENTING CODE WORKS!

    There. Now that I've got that off my chest: what does that method name translate into SQL as? (Wow, even the question feels like a category error.)

  • (nodebb) in reply to tahir_ahmadov

    You obviously have little idea about the usefulness of this library. As Remy wrote,

    List<Whatever> findDistinctByTenantId(String tenantId);

    is easy to read, easy to write and quite self-documenting.

    I still wouldn't do it for any more than a single variable, though.

  • RichP (unregistered)

    postFristPostUnlessFristAlreadyPostedThenPostBlakeyRant

  • (nodebb)

    Ah! This inspires a solution to the other "constants" problem! This can avoid those Constants classes containing --- well --- constants, thousands of them. Instead they could be auto-generated. So whenever you use 

     sec <= CONSTANT_60_times_60
    , the system will automatically convert it to 
     sec <= 3600
    !

    No more hard-coded constants!

    No more tedious long files containing thousands of constants definitions!

  • (nodebb)

    This may not be the [stupidest] method name ever, but it’s certainly a strong contender.

  • Supersonic Tumbleweed (unregistered) in reply to tahir_ahmadov

    Or just use annotations with SQL or any DSL for that matter

    @Query("INSERT your_query CAST AS any(domain_specific_language) WHERE programming_language="Java"") Result<> function(DSL dsl) { [...]

  • (nodebb)

    344 characters long? STAHP!

  • (nodebb)

    This was my submission, and to my coworker's credit, he knew this was utterly crazy and only did it to see if it was possible. All of our other repository methods have much more sane names.

    To Watson who asked what the generated SQL is: "select distinct ad0_.ad_id as ad_id1_1_, [...15 more fields...] from ad_t ad0_ left outer join flag_t flags1_ on ad0_.ad_id=flags1_.ad_id where ad0_.tenant_id=? and (upper(ad0_.title) like upper(?)) and (flags1_.flag_id is not null) and flags1_.resolution_type=? or ad0_.tenant_id=? and (upper(ad0_.description) like upper(?)) and (flags1_.flag_id is not null) and flags1_.resolution_type=? or ad0_.tenant_id=? and (upper(ad0_.email) like upper(?)) and (flags1_.flag_id is not null) and flags1_.resolution_type=? or ad0_.tenant_id=? and (upper(ad0_.contact_name) like upper(?)) and (flags1_.flag_id is not null) and flags1_.resolution_type=? order by ad0_.post_date desc, ad0_.title asc limit ?"

    This is my first time inspecting that SQL. It appears to be a pretty literal translation of the method name, which generates SQL as inefficient as the length of the method name would imply. I might push a little harder for a refactor of this after checking out the SQL.

  • SyntaxError (unregistered)

    ORM in general are garbage. Some are a better abstraction, but at best its still a leaky abstraction. The queries may start out simple and lend itself well to these kinds of solutions, but inevitably they always get more complex. I find it just easier to write out the sql by hand rather than have to know the ORM works AND how sql queries work.

    I was unaware Spring Data did this kind of thing. Grails with its GORM is another notorious offender of this "style".

    Spring JDBC is a good middle ground above jdbc: it doesnt hide the fact that youre dealing with SQL, but reduces a lot of the boiler plate (not all of it) needed to ask the database a question. If your data is best modeled by objects, then why use relational data? You should consider using a NoSQL database. That would avoid the object relational mismatch problem altogether.

    http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern https://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html

Leave a comment on “Longer Isn't Better”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article