4 ms·
>It’s inefficient to read the list of swear words every time swearfilter is called (and similarly for checkban and checkAdminIP) Agreed, its not efficient. >T
by ehonda 7y ago
>It’s inefficient to read the list of swear words every time swearfilter is called (and similarly for checkban and checkAdminIP)
Agreed, its not efficient.
>The way it is implemented, you’ll also have quite a few false positives
Yes. The filter is only for a handful of swearwords, I wouldn't bother making it larger since people can easily circumvent it with various characters.
>Also, is it common idiom in Go to both defer f.Close() and manually call f.Close()? Seems noisy to me (and would, in many other systems, give an error when the deferred code tries to close an already closed file)
Honestly, I don't know. This was just based on some file io tutorials I referenced. Might be able to not have that defer statement at all. I haven't tried.
>Other issue: from glancing at the code, the 403 page doesn’t seem to return a 403 status code.
Good catch.
- Someone 7y ago”Yes. The filter is only for a handful of swearwords, I wouldn't bother making it larger since people can easily circumvent it with various characters.” That’s not the problem I mentioned. False positive means cases where your filter thinks it sees a swear word, while there is none. Cases where there are swear words that the code doesn’t detect are false negatives. ”Might be able to not have that defer statement at all” That wouldn’t be robust. defer guarantees the file gets closed, no matter how the function is exited. That’s what you want (almost all the time). It’s the close just before returning that’s superfluous.