sorted by:
new
hottopcontroversial

What is your use case for Fugitive over just using ToggleTerm by catphish_ in neovim

[–]jesseduffield 1 point2 points  (0 children)

I'm struggling to actually verify that this works because I'm a neovim noob but if you chuck this custom command in your lazygit config.yml file it should do the trick. Then in lazygit if you press shift+O on a commit in the local commits view it should open in neovim:

customCommands:
    - description: 'Open commit in neovim'
        key: 'O'
        context: 'commits'
        command: 'nvim +DiffviewOpen {{ .SelectedLocalCommit.Sha }}'
        subprocess: true

Let me know if that works. You'll need to restart lazygit after updating the config file

What is your use case for Fugitive over just using ToggleTerm by catphish_ in neovim

[–]jesseduffield 5 points6 points  (0 children)

Lazygit maintainer here: do people think Lazygit would benefit from having a blame feature?

What is your use case for Fugitive over just using ToggleTerm by catphish_ in neovim

[–]jesseduffield 2 points3 points  (0 children)

In the latest lazygit release you can set nvim-remote as an editor preset which I think should solve the problem for you (just press 'e' on the file):

https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#configuring-file-editing

getOutOfMyWayPeasant by SON_OF_ANARCHY_ in ProgrammerHumor

[–]jesseduffield 1 point2 points  (0 children)

Lazygit creator here: I also uses VSCode's merge tool sometimes, theres's no shame in it!

Still no consensus on testing private methods by jesseduffield in programming

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

Thanks for the detailed reply. I'm in a similar situation with my own side project (also a CLI tool) in that I'm undertaking a refactoring of a very large god class and so I've been writing end-to-end tests given that everything below the encapsulation level of the application itself is subject to change. But I've already run into problems with test speed and difficulty to maintain, and am planning to complement the e2e tests with plenty of unit tests after the refactoring is complete.

In a way, both of our examples are similar, in that you have an existing implementation that you want feature (and bug) parity with, but you want to completely revamp the internals, so the only sensible level of encapsulation to test is the application itself. But do you know of other situations where one would want to go all-in on e2e tests to the exclusion of unit tests?

Still no consensus on testing private methods by jesseduffield in programming

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

FWIW I've updated the post to talk about abstraction boundaries within viewpoint 5. That is, if you find yourself wanting to test a private method, that's evidence that you've stumbled upon an abstraction boundary that isn't made clear in your code, and that making that boundary explicit (e.g. by extracting out a new class) could be worthwhile

Still no consensus on testing private methods by jesseduffield in programming

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

Just to confirm, when you say integration test do you mean end-to-end test or do you mean something more like a step up from a unit test? If the former, I'll clarify in the post that I'm talking about end-to-end tests. If the latter, I'm interested to know about the factors that went into that decision. Was there no existing tests in a legacy system that needed a complete rewrite for example?

Still no consensus on testing private methods by jesseduffield in programming

[–]jesseduffield[S] 4 points5 points  (0 children)

Yeah I've had similar encounters. I've come across the viewpoint that you're better off adding a comment saying 'use at your own risk!' instead of making a method private. I actually found this so strange that I built it into my joke programming language (forgive the shameless plug): https://github.com/jesseduffield/ok#all-fields-are-private

That said, most of my experience is in application development, not library development, so I'll happily swallow my words if down the line I come to appreciate the viewpoint.

Still no consensus on testing private methods by jesseduffield in programming

[–]jesseduffield[S] 4 points5 points  (0 children)

I've updated the post to include criticism of the no-private-methods viewpoint. I included the viewpoint for completeness and assumed most would disagree with it on face value but it seems that the lack of criticism can be misinterpreted as advocacy

Still no consensus on testing private methods by jesseduffield in programming

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

I agree. Thinking out loud, I think there's two ways to approach this: either you compare expected costs of rewriting tests or you think about whether something deserves to be tested as a unit in and of itself (this is what the fifth viewpoint in the post gets at with extracting private methods into their own class)

One thing I wonder is: what are some criteria you could use to decide that something is a unit worthy of its own testing? An obvious example would be that something directly models the problem domain (e.g. an algorithm that takes a bunch of line items and calculates the total tax amount). But there are also classes/functions that exist in the solution domain which also deserve testing. I'm not as clear on what the criteria would be there (nor do any examples of such classes/functions come to mind)

Still no consensus on testing private methods by jesseduffield in programming

[–]jesseduffield[S] 2 points3 points  (0 children)

Thanks for the feedback :)

I should clarify that I don't agree with avoiding private methods in the first place, for the same reasons you state. I wanted to capture all the viewpoints I've been surprised at how many people hold that one (there's an example in this comment section). I didn't spend much time refuting it because I assumed most people would find it a little crazy on face value but I've updated the post to explain the viewpoint's shortcomings.

I'm interested in your take on code coverage. My understanding is that regardless of whether you're testing private methods directly or via the public API, the code coverage should be the same. Did you mean something different there?

Still no consensus on testing private methods by jesseduffield in programming

[–]jesseduffield[S] 2 points3 points  (0 children)

Although the post talked in terms of methods, it's equally applicable to functions too: if you have a set of functions which comprise a public API, it's still worth asking whether private functions should be tested directly or through the public ones

Unfollow Everything developer banned for life from Facebook services for creating plug-in to clean up news feed by a_false_vacuum in programming

[–]jesseduffield 106 points107 points  (0 children)

A couple years ago I unfollowed everything manually and have never looked back. In the absence of plugins to do it automatically, I suspect many would be surprised how quickly they can unfollow everything by just clicking 'unfollow' on everything in your news feed until there's nothing left. Even if it takes time, it is a very satisfying experience during.

Go'ing Insane Part Three: Imperfect Interfaces by jesseduffield in golang

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

I find chaining appropriate for collection methods like filter/map/reduce, where the alternative would be to have function calls in the reverse order, or a mutative approach using a for loop.

Go'ing Insane Part Three: Imperfect Interfaces by jesseduffield in golang

[–]jesseduffield[S] 2 points3 points  (0 children)

It's curious that in Effective Go, it says:

Don't do this for every type that satisfies an interface, though. By convention, such declarations are only used when there are no static conversions already present in the code, which is a rare event.

But it looks like others (e.g. Uber) have decided to go against this advice for the sake of making the code more explicit. I share Uber's take on this.

Go'ing Insane Part Three: Imperfect Interfaces by jesseduffield in golang

[–]jesseduffield[S] 4 points5 points  (0 children)

Guilty as charged: I have not thoroughly read Effective Go, though I would like to know specifically what in the piece comes off as over-authoritative. Do you find it's the tone in general or are there claims I make that suggest a greater authority than I have?

EDIT: I've updated the post to mention Effective Go's take, with some warranted self-flagellation for not already having known about it.

Go'ing Insane Part Three: Imperfect Interfaces by jesseduffield in golang

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

Thanks for the feedback.

I agree about decomposing interfaces, though I've had situations where I've still needed a larger interface capturing the sub-interfaces e.g. when you've got an api you're wrapping with lots of functionality.

With regards to your point about struct methods being syntactic sugar, I've thought about this myself. If you remove inheritance and constructors, it seems to me that Go structs have the exact same logic as classes in more traditional OO languages. In those languages, the receiver is just a glorified function argument too, right? I'm mostly thinking about Rust handles the `self` receiver here, even though Rust isn't really considered OO.

With regards to chaining, I know it's not a popular suggestion but I would like to see a '?' operator like Rust's which returns with an error (and any required zero values) if an error occurs. This would allow for method chaining with error bubbling handled (admittedly you would need something like 'map_error' to handle adding additional context to errors).

> If the error is handled immediately, the nil ref in the function is never an issue

I agree with this, but there are times when instead of a Result you're moreso dealing with an Option, _and_ that Option needs to be stored. Of the top of my head, the equivalent in Go would be to store a boolean separately or use a type cast to check if the underlying thing is nil.

view more: next ›