summaryrefslogtreecommitdiff
path: root/posts/2015-07-25-dont-remove-white-spaces.org
diff options
context:
space:
mode:
authorFranck Cuny <franckcuny@gmail.com>2016-08-04 11:12:37 -0700
committerFranck Cuny <franckcuny@gmail.com>2016-08-04 11:12:37 -0700
commit2d2a43f200b88627253f2906fbae87cef7c1e8ce (patch)
treec65377350d12bd1e62e0bdd58458c1044541c27b /posts/2015-07-25-dont-remove-white-spaces.org
parentUse Bullet list for the index. (diff)
downloadlumberjaph-2d2a43f200b88627253f2906fbae87cef7c1e8ce.tar.gz
Mass convert all posts from markdown to org.
Diffstat (limited to '')
-rw-r--r--posts/2015-07-25-dont-remove-white-spaces.org65
1 files changed, 65 insertions, 0 deletions
diff --git a/posts/2015-07-25-dont-remove-white-spaces.org b/posts/2015-07-25-dont-remove-white-spaces.org
new file mode 100644
index 0000000..353edea
--- /dev/null
+++ b/posts/2015-07-25-dont-remove-white-spaces.org
@@ -0,0 +1,65 @@
+I don't like trailing white spaces in my source code. I've configured my
+editors to highlight them so I don't add them by accident, and when
+possible, I remove them. But it doesn't mean that all of them should be
+removed blindly.
+
+In this post, I'm talking about files that are managed by a SCM. When
+working on such a text file, editor's hooks that delete them when
+writing a file can be more annoying than keeping them in place. A change
+should only touch lines that are relevant to the fix or feature beeing
+added. Touching lines that are not relevant are creating noise in the
+history. I've made this mistake in the past, and I've learned my
+lessons.
+
+** Pain for the reviewer
+
+The person who will review the change will have to make an extra effort
+to understand why the diff highlight some lines where it looks like
+there's no change. It's a distraction to his main task, and it doesn't
+bring any benefit to the change beeing submitted.
+
+** Pain for the person browsing the history
+
+When someone browse the history and try to understand what changed
+between two versions, the deletion is just noise. It's already hard to
+make the mental effort to read a diff, and understand what and why
+things have changed. Adding some extra noise is annoying.
+
+Running a tool like =git blame= shows how useless this is, for both the
+person reading the history and the author.
+
+** Tips
+
+Configure your editor to highlight them. If you are using Emacs, you can
+do it with
+
+#+BEGIN_EXAMPLE
+ (require 'whitespace)
+ (global-whitespace-mode 1)
+ (setq whitespace-style '(face trailing tabs tab-mark))
+#+END_EXAMPLE
+
+With vim, you can add the following:
+
+#+BEGIN_EXAMPLE
+ set list lcs=trail:·,tab:»·
+ highlight ExtraWhitespace ctermbg=red guibg=red
+#+END_EXAMPLE
+
+It's also possible to configure =git= to highlight them when running
+=git add -p=, by running
+
+#+BEGIN_EXAMPLE
+ git config --global core.whitespace trailing-space,space-before-tab
+#+END_EXAMPLE
+
+=git= will complain if it finds white spaces in your change, so you have
+time to fix and remove them.
+
+If you really don't want any trailing white spaces, you can also
+configure your SCM with a post-commit hook to reject commits that
+contains them.
+
+If you're using =vimdiff= to read a diff, it's possible to not highlight
+white spaces with =set diffopt+=iwhite=. This can makes it a little bit
+easier to read messy diff.