🛠️ Repo: Pointless function in nyancat reporter implementation #2916
Labels
area: reporters
involving a specific reporter
status: accepting prs
Mocha can use your help with this one!
type: chore
generally involving deps, tooling, configuration, etc.
Some of our reporters use
console.log
, others useprocess.stdout.write
. Nyancat useswrite
. What iswrite
?This isn't being used to pass
process.stdout.write
into anything else without having to bind it toprocess.stdout
, it's just being called directly, so all it does is omit the textprocess.stdout.
. Furthermore, I reviewed the file's commit history and wasn't able to find any evidence that it was ever used differently than it is now, nor was it at any point implemented differently (the only change in these three lines was to add a space after the function name), and it goes back to the reporter's original commit.(In terms of metrics, this function plus its JSDoc adds nine lines to the file, but it's only about 150 bytes while it would be about 350 bytes to add
process.stdout.
to everywrite(...)
call, thus it costs 9 lines and saves about 200 bytes. Just in case anyone cares. I don't think it matters to anything but coverage line and function counts.)If this were something any of the other reporters were also doing, I'd chalk it up to being a preferred style; if the
write
function were in its own module and being used by other reporters, I'd say cool, we can make any updates to the implementation in just one place... As is, it just looks like a needless function that needlessly makes this reporter's implementation look different from the others when it really isn't. (Then again, maybe if it werevar write = process.stdout.write;
up front, a lax = require("whatever").x
, I'd have a different impression despite that being technically nearly identical assuming it works at all [no binding needed].)Anyone feel strongly for or against removing it? Part of me doesn't want to clutter the file's blame history with a change from
write
toprocess.stdout.write
all over. But it seems like an obvious cleanup.The text was updated successfully, but these errors were encountered: