July 19, 2012
I’m dropping Camel Case convention
I was watching a video about BDD and decided to try the technique with an exercise. What is happening is that I’m starting to question the Camel Case convention. After a couple of lines of code I have something like:
public void shouldHaveFirstTransitivePropertyOfInequality() { assertTrue(valueUnderTest.compareTo(valueExpectedToBeBiggerThanExpected) < 0); assertTrue(valueExpectedToBeBiggerThanExpected.compareTo(anotherValueExpectedToBeEvenBiggerThanExpected) < 0); assertTrue(valueUnderTest.compareTo(anotherValueExpectedToBeEvenBiggerThanExpected) < 0); }
Full sentences in the method names. Yeah, it specifies the expected behaviour of the unit under test, but the question is about readability now.
I tried to remove the camel case to see if the readability improves, and also because I’m not a Lazzy Programmer
public void should_have_first_transitive_property_of_inequality() { assertTrue(value_under_test.compareTo(value_expected_to_be_bigger) < 0); assertTrue(value_expected_to_be_bigger.compareTo(value_expected_to_be_even_bigger) < 0); assertTrue(value_under_test.compareTo(value_expected_to_be_even_bigger) < 0); }
I’m feeling good with the readability improvement, so I will drop Camel Case in my BDD exercises.
One concern I had, when started this BDD exercise, was about the length of the name for objects, fields and methods. Yes, it may look a little odd at first (ohh, the guilty of breaking conventions!!), but like everything else in life, also this code may turn to be better than what I have today. My goal is to improve readability and not follow a convention.
The video is from Dave Astels (http://techblog.daveastels.com/) and is here: http://www.youtube.com/watch?v=XOkHh8zF33o
I think you want to try python 😉
probably 🙂