Hacker News Reader

Comment by seti0Cha | Hacker News Reader

Beyond that, engineers have different ways of approaching problems and of crafting the code. TDD may actually work great for one engineer, but be terribly disruptive to another. Engineers working in IDEs tend to have a different idea about what constitutes readable code than ones working in basic editors. There is no one way of writing code that is ideal for every coder.

View on HN

TDD, as the top-most comment correctly points out <https://news.ycombinator.com/item?id=32509268>, relies on having requirements against which to test, and as very best I can tell, requirements aren't "Agile" because (pick one:) (the users don't even know what they want || there's never time to do it right, but there's always time to do it over)

don't even get me started on the "basic editor" versus IDE war; that's a topic that 100% of the time grinds my gears

Agile isn't about requirements in the sense of "all behaviour of this project must be specified up front" but that doesn't mean for small slices of validated or to be validated behaviour we can't say "this is what it should do" (otherwise nothing sensible would ever get written?)

From that point of view, a developer has what they need to move forward with TDD (or any other process of their choosing).

I've been wanting a documentation system that lets me "cite" tests in support of a claim, such that when a test fails the programmer can see what claims that test was meant to support, which is crucial context in deciding how to fix the code, test, and/or docs.

You just need a testing framework that supports specifying context.

I write my JVM tests mostly using Spock[1] as it's absolutely great at letting me specify, and ecouraging me to do so, as much context as I can.

It may look something like this (this example is loosely based on Spock using Geb[2]):

    @Narrative('''
    Users can choose to authenticate using method A or B.
    This test makes sure that users can choose one or the other, go back and
    change their decision later, and complete the procedure with either method.
    ''')
    class AuthenticationMethodsSpec extends Specification {

        def 'Users can choose method A'() {
          given: 'the user goes to the login page'
          goTo(LoginPage)

          when: 'the user chooses method A'
          page.click('methodA')

          then: 'the user goes to the method A login page'
          at LoginMethodA
    }

Error messages are great too... and the tests, at least when written as above, with actual contextual information everywhere necessary, are much better than the usual JUnit abominations you're likely to find in Java shops.

It may look superficially similar to Cucumber, but it's IMO much better because it's just Groovy code (and I happen to really like Groovy, some people have trouble with it because it's "not exactly like Java"), no custom parsing of text-based stuff and other complex gimmicks.

[1] https://spockframework.org/spock/docs/2.1/index.html

[2] https://www.gebish.org/

Sure there are other factors that are involved, but my point was, some coders are more deliberative while others are more exploratory. I'm in the latter group. I think by writing code. I do lots of refactoring and sometimes start over. Writing tests in the middle of that process would result in lots of thrown away test code and a much slower exploration of the problem space. Other coders think through problems first and know what they want before they start. They are more likely to benefit from something like TDD.

Above all else, TDD requires that... ... ...you like working that way.

I dunno why the TDD folks specifically get so zealot-y about it being the one-True Way™. I'm happy that they've found something that they like and are passionate about, but, damn... it seems like they missed the episode of Power Rangers where you learn that different people will like different things than you do, and that that's okay. They don't have to be "wrong" for you to still enjoy your TDD.

> Engineers working in IDEs tend to have a different idea about what constitutes readable code than ones working in basic editors.

I do like beautiful punch card layouts, too. But I'd still not hire someone who uses punch cards to write java. If one cannot configure the "basic editor" to provide basic semantic tools IDEs had for 20 years, then I don't care much about opinions on readability...

I can see arguments either way. IDEs allow people to create complex code effortlessly so the resulting code tends to be more complex. Forcing developers to remember names and file locations causes the developer to try and encapsulate the complexity so they don't have to remember as much. Also, I often need to read code outside of an IDE. If the code was written to be understood that way, it tends to be easier. If I'm going to be living in a single codebase for a long time, I love a good IDE. Having good refactoring tools is awesome. But I often jump around across many codebases across multiple languages and I appreciate if I can make sense of them without firing up some specialized tool.

What situations do IDEs add a bunch of difficult to read code? Auto-adding lines of code for importing things, closing blocks, hints while typing are all pretty clean. I do, however, think Typescript adds a lot of LOC where it often seems unneeded for a responsible developer.

It's not the IDE adds difficult to read code. It's that it makes it easy to write difficult to read code. This is particularly visible in the Java world. For example, the practice of dropping interfaces in front of everything never would have seemed reasonable if you didn't have an IDE that could do that with the click of a button, and the ability to quickly click through an interface to an implementation makes it relatively painless to work with. However, a person without access to an IDE is forced to use text searches to find implementations and has to keep in their head how all these interfaces and classes are organized. Similarly, IDEs make using complex method signatures tolerable with parameter hinting, makes finding method overrides trivial, and autocompletes all those long similar-sounding names like FooFactoryBuilderFacadeAdapter.

In contrast, a developer writing code with a plain editor needs to remember everything and when that becomes difficult, the developer will be forced to either simplify things or encapsulate the complexity so they can forget about it. That code base will be easier to read without tooling because it was built to be understood that way. The developer also has to write each bit by hand, which gives time and motivation to wonder whether what they are writing is necessary.

I could make a similar argument in the other direction as well. Code written by hand tends not to get refactored as much, tends to use too short variable names because of typing laziness, or inappropriate names because renaming variables is not trivial as it is in an IDE. I see the advantages of both, and I find myself preferring the sweet spot of intelligent editors that stop short of knowing everything about your code base.

Reply on news.ycombinator.com