I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.

▲

FieryMechanic 14 hours ago | parent | next [-]

> I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster.

In almost every code base I have worked with where warnings weren't compile errors, there were hundreds of warnings. Therefore it just best to set all warnings as errors and force people to correct them.

> Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.

I work with a colleague that doesn't compile/run the code before putting up a MR. I informed my manager who did nothing about it after he did it several times (this was after I personally told him he needed to do it and it was unacceptable).

This BTW this happens more often than you would expect. I have read PRs and had to reject them because I read the code and they wouldn't have worked, so I know the person had never actually run the code.

I am quite a tidy programmers, but it difficult for people even to write commit messages that aren't just "fixed bugs".

	▲	ErroneousBosh 5 hours ago \| parent [-]
		> I work with a colleague that doesn't compile/run the code before putting up a MR. I informed my manager who did nothing about it after he did it several times (this was after I personally told him he needed to do it and it was unacceptable). At this point what you need to do is stop treating compiler warnings as errors, and just have them fire the shock collar. Negative reinforcement gets a bad rep, but it sure does work.

▲

ErroneousBosh 17 hours ago | parent | prev | next [-]

Go is a very opinionated language. If you don't like K&R indentation, tough - anything else is a syntax error.

It's kind of like the olden days.

▲

bluecalm 16 hours ago | parent [-]

Yeah but this case just seem to be strictly worse. It makes experimenting worse and it makes it more likely (not less) that unused variables end up in the final version. I get being opinionated about formatting, style etc. to cut endless debates but this choice just seem strictly worse for two things it influences (experimenting and quality of the final code).

	▲	ErroneousBosh 16 hours ago \| parent [-]
		If you want to leave a variable unused, you can just assign it to _ (underscore) though. IIRC gofmt (which your editor should run when you save) will warn you about it but your code will compile. It's a slightly different mindset, for sure, but having gofmt bitch about stuff before you commit it rather than have the compiler bitch about it helps you "clean as you go" rather than writing some hideous ball of C++ and then a day of cleaning the stables once it actually runs. Or at least it does for me...

▲

treyd 19 hours ago | parent | prev [-]

You're not supposed to question the wisdom of the Go developers. They had a very good reason for making unused variables be an unconfigurable hard error, and they don't need to rigorously justify it.

	▲	FieryMechanic 14 hours ago \| parent [-]
		Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). I work on TypeScript/C# code-bases and unless you force people to tidy up unused imports/using and variables, people will just leave them there. This BTW can cause issues with dependency chains and cause odd compile issues as a result.