Hacker News Reader

Comment by asaph | Hacker News Reader

> So many things have to go right just to get a software program to compile. That’s why attention to detail is so important...

Even the sloppiest coders who work with no attention to detail still compile their code with ease. I get the author's larger point about attention to detail but I don't think compilation is an effective example to illustrate that point.

View on HN

You've been lucky, then. At half the companies I've worked for, there's that One Person who regularly breaks the build for everybody by checking in code that doesn't even compile.

This is 98% of why I push for continuous integration. I don't care about unit tests for their own sake, and I don't bother for my personal projects. I only want CI on a team so that when it turns red, there's an unbiased third-party building the code, and I can simply point to it and "the build is broken, please fix". Otherwise, I have to have the same conversation every week, and it always begins with "Oh, I don't think I caused that!"

Impartial enforcers are worth their weight in gold because they never get emotionally exhausted, they never get uncomfortable, they never back down and can't be argued with.

I've worked with people who struggled to get code to merely compile--and not just in CompSci 101 back in university where this was at least 80% of the programming students. In actual companies where they were hired as software engineers. Granted, they don't last long.

A lot of those folks see compilation success meaning program task is now complete. Some slip through the cracks and graduate.

Agreed. I generally see a lack of attention to detail with regard to things like linting, unit tests, and documentation. Our CI builds fail way too often due to the first two items, which can be easily done via a single build target on a developer's machine.

A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures.

And you can generally set that hook up to be installed automatically through whatever build tool runs your stuff, like gradle for java stuff, or yarn/npm for js/ts stuff.

And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason.

Attention to detail in developer tooling can reduce the amount of details developers have to pay attention to.

> And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason.

In my experience, that is a state that would never end. It would work for a month, then break and would never get fixed again, and would fall into abyss of normalized deviance.

Ah, that's too bad.

We have one managed by yarn where I work, and it's only broken on me once. I occasionally get asked for help (maybe 1/3years/person) when somebody gets a cryptic error (well, not that cryptic, but they ask me because it's git related) from it, and rerunning the hook installation task has always fixed it.

This assumes that we are currently using a sane system. But your point is well-taken.

I'm not entirely sure I want to sit through a 10 minute linting process every time I do a quick `git add -A && git commit -m WIP` locally. Why does it need to be a pre-commit hook instead of a simple PR check? PR checks obviously need to be done anyway.

10 minutes?

A strategy I have used is: - only lint the files that have changed - only apply lint rules that can be auto-fixed

This usually takes less than a second (short enough that you can't really tell the difference) and the developer doesn't have to do anything .

> 10 minutes?

Yes. I work in a codebase that's 30GB checked out. It takes a long time to run our automated checks. That's why they happen on the server, when I make a pull request.

The upshot is the same: it doesn't go to master until checks pass. But who gives a shit about what I'm committing locally? I reserve the right to save my work even if things aren't compiling. You (my teammate) won't see it anyway, it's all locally on my machine. Why do you care?

Your local pre-commit hooks are separate to your remote pre-commit hooks.

There's no such thing as a remote pre-commit hook. Do you mean a pre-push hook? That's a different story, but even then what you really want is to just deny access to shared branches, except to your CI system, which will run your checks before allowing you to merge.

GitHub/GitLab/BitBucket/etc all have this kind of system, it's not new or interesting.

    git commit -m WIP

I hope you're rebasing that terrible commit message away before pushing this remotely.

I hope the pre-commit hook validates the commit message follows the correct format which links the work to the correct ticket number and if you left off the ticket number inserts it for you based off the branch name etc.

No. No. NO.

My commits locally are my business, and 100000% orthogonal to what YOU (my teammate) will see when I'm ready to make a PR. Because I rebase, I reword commits, and I squash things as necessary before I submit a pull request.

The horrible conflation of commits (what I do when I want to save my work) and pull/merge requests (what I do when I want to integrate my work into the repo that everyone sees) is the very reason why git was created to begin with. If you want centralized version control where "commit" means "everyone sees it and it has to pass checks", use SVN. Seriously, get away from my tools.

Yeah, but none of that would be affected right? If you don't prepend the ticket number, it'll do it for you. That gives the entire team a guarantee all the work is traceable. It's a tool that serves the whole team, not just you.

Why should this be done at pre-commit time? And what automated system will be able to guess a ticket number based only on what's in a commit?

I'm all for validation that all commits must have some metadata/ticket numbers attached... at the time it is merged into master. Not on my local machine.

I probably did `git add -A && git commit -m WIP` at least 7 or 8 times today alone. But all my commits that made it into a PR were squashed, divided up logically, and renamed before they went in.

I'm trying to imagine a system where some automated thing prepends "TICKET#123 WIP" before every commit I make, locally, even if they're all getting thrown away before I squash/rebase/reword my commits. What's the point?

> A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures.

Omg don't use commit hooks for that, just make it as easy to use as possible for the developer (e.g. integration into the editor/IDE). For verifying such things CI is the way to go.

Simply never commit directly to your development branch, use feature branches and pull/merge requests.

1. Someone else (ideally the most experienced Person(s) available but even any second pair of eyes is better than nothing) can and should review the code 2. Hook it up to the CI, the CI should merge it into the target branch locally and do its thing, as long as a pull request fails the CI it will not be merged

Software (e.g. Gitlab) to implement such a workflow is freely available, you just have to set it up but that's worth the effort.

Oh god, nobody effing documents anything. It's the bane of my existence. So much time would be saved if people simply documented things along the way.

This can be a double-edged sword when it comes to coding, as code and documentation can very easily fall out of sync. I am in favour of trying to write self-documenting code, with clear unit and variable names, with an automated system to convert that to a human-readable format. Any separate documentation should focus on more areas that are not easily concluded from the code -- like intent, architecture and the like.

Documentation of code tooling is terrible.

I still don't know why we haven't stolen the Photoshop layers paradigm and applied it to code

I should be able to toggle a shallow layer and deep layer all from a single 'file'

So the you'd be able to have architectural notes in the deep layer etc.

In many ways our tools are stuck in time.

Fascinating idea. Though from my experience with a crude approximation of part of it—Javadoc (or the equivalent) that's folded by the IDE—keeping the deeper layers up-to-date would be an uphill battle at most organizations.

Actually, the old Forth block editors did this with their screens and shadow-screens.

The normal unit of editing work in original Forth was a 1024 byte "page" called a SCREEN. You would write your code in an editor that arranged it as 16 lines of 64 characters. At the touch of a key (usually), you could swap to the shadow screen which would have the documentation on it. By convention, shadow screen comments were placed on the same line as the code they were remarking on, so everything was usually co-located.

By abusing autorepeat, it was even possible to "flicker" the code and documentation to see both at once.

Something like CWEB or org-mode permits interleaving code with comments, but it's one dimensional and breaks your flow when editing.

That's why it'd have to be layers and you'd have to have some clever way of keeping what in each layer goes with which code.

I started playing with it a while back in terms of how you'd structure it and what I came up with was something like

   foo.cs
   foo.shallow
   foo.deep

So that all existing tooling would work, foo.cs would just be regular old code and only if your editor supported layers would it care about .shallow and .deep, I didn't like that it would clutter up files.

If I ever get the time I'd like to implement a rough prototype in intellij.

I like this, in addition, I believe in documentation through unit tests. Especially when dealing with edge case business logic. Implement a test that has a verbose name or description testing that logic. If someone breaks it- they are notified through a failing unit test, then they also have a clear reference of why the logic was there in the first place and they know that now they have to go to product to figure out if the logic is still relevant.

I think that "self-documenting code" only covers the what, though. Code, regardless of style or language is fundamentally just a bunch of instructions; the why (and sometimes how, i.e. assumptions/preconditions/platform-level details, and so on) can't really be encoded there.

> I am in favour of trying to write self-documenting code, with clear unit and variable names, with an automated system to convert that to a human-readable format.

That's great and all, and I agree in principle, except time and time again I've witnessed people use the "my code is self-documenting" thing as an excuse not to describe anything they've written in plain English. Much of the time, it's pure arrogance of developers who think their shit doesn't stink.

I'm not expecting people to litter their code with comments explaining what every line is doing. On the other hand, a project that can't even run on a dev's machine without having to repeatedly ask someone questions is unacceptable, and core architecture and concepts should be summarized so that new developers won't eff up or rethink ideas that have already been thought out.

Perhaps they meant to say compile on the first try. Then you need to have at least some attention to detail

Not every development language requires compilation. E.g. python

It's still getting compiled at some point.

At runtime, which is why you need unit tests and linting as part of your development process.

Still requires syntactic correctness to be interpreted. The fact it doesn't generate compiled objects is pedantry.

There's plenty of things which are only caught if actually run. I've certainly seen coworkers push code like:

    if case_that_im_not_going_to_bother_trying_to_test:
        obj.method_which_doesnt_exist()

That's the downside of duck typing, could as well be `obj.method_which_might_get_created_at_some_point_at_runtime()`

I rarely see code in python that I would both like to touch and that uses techniques of this sort.

Reply on news.ycombinator.com