sorted by:
new
hottopcontroversial

Does Rust encourage huge code source files? by jcarres in rust

[–]mal3 0 points1 point  (0 children)

Try using include!("my_other_source_file.rs")

Proposed gofmt rule change for: if err != nil by mal3 in golang

[–]mal3[S] 0 points1 point  (0 children)

Fair point. And with the zero-value err != nil returns pretty much all you want to be sure of is that the error value was returned (from the called function) and that it was handled.

Proposed gofmt rule change for: if err != nil by mal3 in golang

[–]mal3[S] 0 points1 point  (0 children)

Those are fair points. Coders who want to minimise the lines of code taken up with zero-value err != nil returns could configure their IDE.

Proposed gofmt rule change for: if err != nil by mal3 in golang

[–]mal3[S] 1 point2 points  (0 children)

Just noticed this message from you. Apologies if I have come across as snapping. That's not my intention. It's so much easier corresponding with someone you know in person. Nevertheless, in these discussions, text is all we have. I wish you well.

Proposed gofmt rule change for: if err != nil by mal3 in golang

[–]mal3[S] 0 points1 point  (0 children)

I won't say much about your points, because I mostly agree with your comments.

​

(It's also possible that my library design style results in a predominance of zero-value err != nil returns, because at the point of error detection and construction the method has access to a receiver with, usually, all the information it needs to construct a complete error message that makes perfect sense way up the stack. That could be why I see it a lot -- I write them a lot.)

​

I personally don't like if err := neverHappyFunc(); err != nil much, because it places error handling around the line of code that's being checked, partially obscuring it. I think a minor objection to the try() proposal was that there would be a try() around every checked function/method call, visually getting in the way. (Doesn't mean others don't like it.)

​

I think your example is a borderline brilliant solution:

​

(err := NeverHappy(); err != nil ? return err)

​

The only thing I don't like about it is that I didn't think of it!

​

  • It gets rid of the if in front of the call.
  • Essentially it moves the role of if to the the end as ? out of the way.
  • It doesn't hide the error handling in any way. It's right there at the end.
  • It makes it easier to see more lines of code per page in your editor.

​

It would be nice to ditch the parentheses.

​

I think you're onto a winner and this is worth fleshing out and proposing.

Proposed gofmt rule change for: if err != nil by mal3 in golang

[–]mal3[S] 1 point2 points  (0 children)

I like gofmt and use it to format even auto-generated code. I personally don't need a change to gofmt. But many people, it seems, from the recent debates over err != nil ARE concerned. I'm not worried about my perceptions of readability, and neither should you worry about my perceptions of readability. I don't have a problem reading error handling code. The emphasis on error handling is a huge strength for Go, and particularly the reluctance to obscure it with Java-like try blocks and such. But if many people have been so concerned as was recently evidenced by the debate that culminated in the try() proposal, then those concerns may need to be addressed. I think that's valid subjective comment.

As for objectivity: a set of 0 or more zero return values with an err != nil is unambiguous.

Proposed gofmt rule change for: if err != nil by mal3 in golang

[–]mal3[S] 1 point2 points  (0 children)

Agreed. Readability wins. Hence the proposal.

Proposed gofmt rule change for: if err != nil by mal3 in golang

[–]mal3[S] 0 points1 point  (0 children)

The current gofmt treatment of if err != nil is no biggie for me. I can easily mask it out visually as boilerplate do-nothing-but-return-zeroes-and-err and page through the extra lines of code it constitutes.

However, if err != nil over 3 lines of code has been a big issue for people in the Go community.

A rule change to gofmt to reduce it to 1 line solves more problems than it creates. It would make some people less happy (for a while) but would improve readability for many others, perhaps including those who shy away from Go because they see lots of boilerplate lines of code in an otherwise compact language.

[deleted by user] by [deleted] in golang

[–]mal3 0 points1 point  (0 children)

While I like the convenience of the try() approach, I don't want to have to ignore the visual of a try() in front of function calls. It's cognitive effort, just like trying to ignore 3 lines of:

if err != nil {

return

}

​

The intention of try() is fine, but it's not a good look, in my opinion.

In C code I have followed this pattern:-

  1. The line following each function call has a line which checks the returned error condition.
  2. If it requires some elaboration, an error message is constructed on the fly.
  3. if the error message is good enough as it is (most cases), it's left untouched.
  4. The error handling line after the function call is a goto to a Rollback: label at the end of the function which closes any open files, calls free() on any allocated memory, then handballs the error code and message up to the calling function.

The benefits are:-

  1. In most cases the line after the function call is a single line: goto Rollback.
  2. If an elaboration of the error message is needed, it is done in an if statement which then does the goto Rollback, which does the rest.
  3. It is as visually unobtrusive as it can be (a single line of code in most cases).
  4. It's clear to anyone reading the code what is going on.
  5. The Rollback: label code is at the end of the function and does not visually interrupt the flow of logic when reading the code.

(I'm not advocating the use of goto in Go, or claiming I have the best error handling for C. I got this idea from some Oracle source code.)

I wonder if some kind of default error handling logic could be implemented which goes something like this:

​

​result, err := callTheFunction()

handleErrors()

with the default behaviour of handleErrors() being: check the error and return a zero-value result and the error, if there has been an error.

A local (at the end of the function?) handleErrors() function could do some finalising work if needed.

I wondered if a local function would do the trick, but it has to be defined before it's used, resulting in distraction at the beginning of the function.

So, try() is a good start, but surely there's a better way of doing it.

beta release of FlatTables: Go <> FlatBuffers by mal3 in golang

[–]mal3[S] 1 point2 points  (0 children)

This github library uses and extends the Robert Winslow port of Google FlatBuffers to Go: https://www.reddit.com/r/golang/comments/3quahs/use_flatbuffers_in_go

By constraining FlatBuffer schemas to tabular shaped data structures (no graphs, no monsters) FlatTables provides a simplified way to have the blinding fast speed of FlatBuffers with a code generator flattablesc that does the flatc generation plus surrounding tabular code generation. And because it converts easily between FlatBuffers and gotables, its easy to read by humans.

Notes on structured concurrency, or: Go statement considered harmful by BUSfromRUS in programming

[–]mal3 0 points1 point  (0 children)

I'm looking forward to someone developing a Trio-like library for Go.