From 455991f5185208891879d82fd3f54ff6c2a86846 Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Mon, 2 Dec 2019 10:04:35 -0300 Subject: [PATCH] Added a blog post about comments that reflects things I mentioned here --- content/books/things-i-learnt/steps-as-comments/index.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/content/books/things-i-learnt/steps-as-comments/index.md b/content/books/things-i-learnt/steps-as-comments/index.md index e48c74b..56b52c7 100644 --- a/content/books/things-i-learnt/steps-as-comments/index.md +++ b/content/books/things-i-learnt/steps-as-comments/index.md @@ -54,6 +54,13 @@ writing the code between the comments, you write the functionality in the function themselves and keep a clean view of what your application does in the main code. +In [A Comment Is An Invitation For +Refactoring](https://blog.pragmaticengineer.com/a-comment-is-an-invitation-for-refactoring/), +Gergely Orosz points that comments in the code could be converted to function +calls, including things like grouping common things, or bugfixes. This is, +basically, the same thing, except in different points of development: One when +the code is about to be written and one when the code is already there. + [^1]: Yes, that was sarcastic. {{ chapters(prev_chapter_link="/books/things-i-learnt/spec-first", prev_chapter_title="Specs First, Then Code", next_chapter_link="/books/things-i-learnt/gherkin", next_chapter_title="Gherkin Is Your Friend to Understand Expectations") }}