run mandated in the dev chain pre-commit
pre push pre merge pre-build etc what’s
your target coverage I think that what’s
most important is that they are
somewhere pre-emerge they I think the
best place is probably just to have them
in the pull request when you’re doing
code review that is I’ve seen that done
a lot of times and it works really well
that is where you should have your where
verification happen in my opinion I
don’t like when people put them as
pre-commit hooks because when I work I
do a lot of incremental commits and I
use a use version control very
aggressively yes like a progression of
my work as a way of structurally saving
my progress and keeping me working in
small increments and sometimes I just do
these work-in-progress comments and and
I can do those like on the train while
I’m just closing my laptop down and
walking out the door and stuff like that
and when people have pre-commit hook I
there are absolutely in my opinion
they’re all legit legitimate cases where
you want to commit even if your your
tests are not passing I especially also
dislike when people run linters in in a
pre commit step because in my world I
guess styling is something that I look
at at the end of my development cycle
like right before I do the pull request
I go through the styling issues I don’t
want to get caught up in that while
while I am working and solving the
problem because then I start keeping
multiple things in my head it’s the same
reason why when we back when I was into
video production shooting shooting shows
we when we work with scripts we didn’t
use any of the software
or word processing like software where
there was formatting we always use just
plain text editors when writing yes so
that we would be focused on the writing
itself and not the not get distracted by
the formatting or starting use
formatting as a way of procrastination
as for target coverage um I don’t know
like I don’t bother too much where the
coverage code coverage is yeah it’s just
too blunt of a metric to be interesting
however what I do is in there when doing
code reviews I go into the I check out
the code and then I take some of the
change lines and I just fiddle around
with them change a variable here and
change a value here and basically try to
break the code and see if the tests that
were added also break when I when I
break the code that they are supposedly
testing I found that this is a great way
of making sure that code that is being
added has tests and that those tests actually validates the code