4 ms·
`method names that can have spaces - and dashes - in them` Eugh, that is a turnoff. Maybe I have programmer Stockholm’s, but at least with a single connected w
by 0cf8612b2e1e 2y ago
`method names that can have spaces - and dashes - in them`
Eugh, that is a turnoff. Maybe I have programmer Stockholm’s, but at least with a single connected word, I can always double click to select the token. Maybe, I might have wanted dashes at some point, but spaces seem like a step way too far.
- ditn 2y agoGenerally these are only used in test methods, which is fine. I've never seen anyone use them outside that.
- recursive 2y agoWhat benefit do they provide in testing scenarios? I've never written Kotlin, but from an outsider's perspective, it seems like a slim benefit, outweighed by the cost of the mere existence of this syntactical oddity in the language's grammar.
- t-writescode 2y agoWhen writing tests, you can name the methods more useful things, such as: class MyTestableClass { fun `methodName - when input does not parse to valid regex throw exception`() { } } It's pretty clear what is under test in a situation like that. That's basically the only situation I ever see it used in (and would code-smell the heck out of it if I saw it in other circumstances). People who are familiar with RSpec-style testing are very used to this sort of thing. describe MyTestableClass do context 'input parsing issues' do context 'when not valid regex' do it 'throws exception' do ... end end end end Anecdotally, I've also found that such style naming for tests allows me to write out the desired names for all the tests ahead of time more easily and then implement them. That happens to be my flow.
- codedokode 2y agoI like how tests are made in Python - you don't even need classes, just functions, and use a single assert keyword for everything. Also it's easy to parametrize them using decorators.
- t-writescode 2y agoParameterized tests are a huge, huge win, yeah. I am a big fan of them and look for how to do them in every test framework I use. RSpec was the weirdest for me; but NUnit and JUnit have been quite easy, and I'm not surprised at all they're easy in Python too (admittedly, I don't remember if I ever wrote them in that language).
- stickfigure 2y agoParameterized tests in Junit are basically the same as decorators: @ParameterizedTest @ValueSource(strings = {"first", "second"}) void fooGoesBar(String param) { ... } Also, once you get used to assertj, you'll never want single-assert again. It's fantastically useful to know (for example) not just that two lists aren't equal, but specifically what elements differ.
- codedokode 2y ago> It's fantastically useful to know (for example) not just that two lists aren't equal, but specifically what elements differ. Pytest shows the diff as well when using assert: > assert y == x E assert [1, 2, 3] == [1, 4, 3, 6] E E At index 1 diff: 2 != 4 E Right contains one more item: 6 E Use -v to get more diff
- stickfigure 2y agoGreat, what's the equivalent of this? assertThat(someCollection).map(Thing::getValue).containsExactlyInAnyOrder(3, 4, 5);
- codedokode 2y ago
- benatkin 2y agomethodName_whenInputDoesNotParseToValidRegexThrowException They did a study and it isn't hard to read camelCase. https://ieeexplore.ieee.org/document/5090039 https://ieeexplore.ieee.org/document/5090039
- richbell 2y agoI mean, it's harder to read compared to normal text with spaces and punctuation.
- benatkin 2y agoThat doesn’t seem to be the case based on the study. And normal for one thing, such as paragraphs of prose, might not translate to another thing, such as a sequence of words in a line of code.
- richbell 2y ago> That doesn’t seem to be the case based on the study. The study does not say that camelCase is unequivocally as easy, or easier, to read. Selecting the correct identifier from a list of 2-3 words (expandAliasTable, expandAliasTitle, etc.) is a wholly different exercise.
- yearolinuxdsktp 2y agoAh thank you for actually reading the referenced study
- grapesodaaaaa 2y agoThat’s just one study, and I’d argue we should write books in camel case to make them more compact if there’s truly no difference.
- t-writescode 2y agoSure, but I like writing the other more. It's entirely a style thing and you're not required to do it :) it's also basically only ever seen in tests :)
- karmakaze 2y agoIn the RSpec case, those don't have to translate to method names with embedded spaces. It seems that using fun `...` instead of a dsl: test "..." is the mistake.
- usrusr 2y agoIt's a place to put intetion that isn't so much of a second class citizen that it will likely be ignored and/or not updated if it ceases to be true. You want your test methods fine grained (many methods that each check one variation, instead of one method that checks a whole list of them) and every extra redundancy (method naming vs the variation of data actually passed vs documentation) increases the the chance of those redundancies getting out of sync. In fact I've occasionally found myself writing reflection code to parse the test method name as input just to avoid that problem altogether (for name and data, not for documentation). And that was in plain Java even, the pattern could be far more useful with that kotlin naming freedom.
- grapesodaaaaa 2y agoThe test frameworks typically output the passing/failing function names. Adding spaces like this make them more human readable. expectInternalServerErrorOnBadInput Vs expect internal server error on bad input
- NitpickLawyer 2y agoIsn't this breaking Jakob's law of the rest of the tooling though? I can se flows borking with something like "x failed at expect" in a majority of reporting tools not specifically meant to deal with this spaces in functions stuff.
- yearolinuxdsktp 2y agoNot really—-most CI reporting is based off junit/testng report XML files. I doubt your CI reporting is parsing out test names with regexes out of log files.
- wiseowise 2y agoSo that programmers have one more bikesheddibg reason, obviously.
- irunmyownemail 2y agoIt reminds me of Spock tests written in Groovy. I have to help maintain a code base like that now at work where a Groovy zealot (who has moved on) convinced the teams to write tests in Groovy instead of Java. When a test fails, the method name describes what it was supposed to do written out like a sentence enclosed in double quotes which seems like a win but not much of one. When you need to add a new test or analyze if an existing test needs to be changed, you have to eyeball all the code in the test class because even with methods named with spaces, it's not always indicative of what it does. With Java, I can sort a list of method names and have a better idea immediately what needs to be updated or added.
- deleted 2y ago[deleted]
- yearolinuxdsktp 2y agoSpock is an exercise in syntax cleverness with regular confusion opportunity and little gain IMO. Way too much implicit syntax that IDEs struggle with. Refactoring Spock tests sucks due to how the context is different based on the clause you’re in.
- erik_seaberg 2y agoIt’s better to quote a reserved word than to be unable to use it.
- thaumasiotes 2y ago> Maybe I have programmer Stockholm’s, but at least with a single connected word, I can always double click to select the token. If you're using anything that can do syntax coloring correctly, you can still do that.
- Freak_NL 2y agoWhile that is avoidable by sticking to a coding style, that horrid and unavoidable 'fun' instead of 'function' (or 'fn') just saps my will to work on such a codebase.
- t-writescode 2y agoThe best part about lots of languages being around is that you can pick the one that resonates most with you :)
- wiseowise 2y agoRight. You have selection of Kotlin and Kotlin in Android/Kotlin heavy company.
- coldtea 2y agoIf that's the case, it doesn't sound there was much will to work to begin with...
- int_19h 2y agoWhy do you hate fun so much?
- RedComet 2y agoAgreed. Obviously `func` wasn't going to happen because it is already so similar to Swift, but `fn` at least should be an option.
- aembleton 2y agoI like it for unit tests. Makes naming them easier
- coldtea 2y ago>Eugh, that is a turnoff. That's because you're too used to C/Algol style languages
- usrusr 2y agoAs others have said, I would not expectany any style guideline to tolerate those names outside of tests. But it's not entirely test-only: When you are dealing with code generation for schema defined in/for other languages, being able to just drop names in backticks and be done with it would be far less hassle than making up your own transformation and deciding between verbosity and safety from collisions.
- badsectoracula 2y ago> at least with a single connected word, I can always double click to select the token I'd expect an IDE for Kotlin to detect `stuff like this` and select the entire name. Considering Kotlin came from JetBrains, IDEs are most likely already in the Kotlin community's DNA. (i never wrote or anything related to Kotlin myself but i do appreciate IDEs helping with stuff like this)
- eptcyka 2y agoThis also means that JetBrains will never write a language server for Kotlin, locking you into their ecosystem.
- int_19h 2y agoIt doesn't lock you into their ecosystem given that other people can (and have) written language servers for Kotlin.
- eptcyka 2y agoWhich are not nearly as capable and will forever be catching up. For a better situation look at Apple’s sourcekit. I’d take kotlin over swift in less than a heartbeat if it was more open source than Swift. Which us a very low order.
- t-writescode 2y agoHow’s Apache 2? https://github.com/JetBrains/kotlin https://github.com/JetBrains/kotlin
- wiseowise 2y ago> Considering Kotlin came from JetBrains, IDEs are most likely already in the Kotlin community's DNA. Idea understands and performs dramatically better with Java.
- 2y ago
- wiseowise 2y agoName is wrapped in ``, so it’s not “true” use whatever you want. You also have to use `` on call site.
- paulddraper 2y agoThe better benefit is that you can use the right name for something instead of tiptoeing around reserved keywords.
- jeroenhd 2y agoThe feature isn't just about spaces. It's also how you'd work around interacting with JVM code that uses what would be Kotlin keywords. For instance, Java classes with a method named "is" or "val" can be called through val isBar = foo.`is`(bar) rather than needing to use reflection like you would to accomplish the same in Java. The Kotlin style guide basically says "never use this outside of test names" and some targets, such as old Android, don't even support the feature in test cases.
- yearolinuxdsktp 2y agoIf you use a good IDE it will select the whole method name. In general you would not use spaces for method names of anything that’s a shared/common use facility. They are best used to give test methods readable names. E.g. “test parallel writes are thread-safe”. And not “write with timeout.”