This blog post is part of a series of blog posts concerning a Clean Code study circle that we developers at Admeta are persuing during 2009. Here you can find an introduction concerning the question why we are doing this and here you can find an overview of all chapters as well as some study circle recommendations.

Questions: Chapter 2 Meaningful Names

1. What do you think is the characteristics of a good name?
2. Do you take IDE Code Completion into consideration when labeling namespaces, class names and its members?
3. Have you reflected upon "noise words" in names before?
   
4. If you have a class property of type int named Age, but you discover that you would actually want an Age property of type string as well. How would you handle this?
5. Are you or have you been using Hungarian Casing? Why? Do you agree with the books statement that it should not be used in modern languages?
6. Having a prefixed I for interface is an established Microsoft convention. Do you agree with this? Why?
   • Extra (Design considerations): Interface vs Base classes [1], [2], [3], and [4].
7. Do you think "Duck Typing" is something good and do you see Duck Typing as possible in a typed language as C# v3?
   • How far should we utilise the support for Duck Typing in CS 3?
8. Would you consider complexity of code as a beautiful thing or do you agree with the books ways of seeing such practices to write complex code deliberately as a personal quest to show off mental capabilities?
9. Is there any benefit of using constructor (or a static factory method that produces the object) as a way to inject dependencies compared to properties/mehtods?
10. Design: So you find the concept of Value Object as a useful pattern?
11. What is your opinion on PascalCasing and camelCasing?
    • Do you have a deviating opinion from Microsofts recommendations of when to use which?
12. Are there any rules in Chapter 17 that you think originates from this chapter?
    • Is there any rule that you are missing from what you have read in this chapter?

The context of our study sessions is restricted to .NET and C#, thus the nature of the questions above. 

This blog post is part of a series of blog posts concerning a Clean Code study circle that we developers at Admeta are persuing during 2009. Here you can find an introduction concerning the question why we are doing this and here you can find an overview of all chapters as well as some study circle recommendations.

Chapter 1 Clean Code questions:

1. Before reading, take a moment to reflect what the concept of Clean Code means to you.
   • Is there anyone of the different "guru's" description of Clean Code (p7-12 + forword) that do you think lies closest to your own definition of Clean Code?
   • After having read the chapter, has the reading changed your conception?
2. What is your experience / opinion of code generation tools or any other higher abstraction level of programming (4GL)?
   • Do you have any good or bad experience of building your own code generator (in some way)?
   • Where do you think we are heading when it comes to abstraction levels in languages and tools?
   • Do you consider this to be a bright future for us developers?
   • extra: What do you think of Joel Spolskys described "The Law of Leaky Abstractions"?
3. Have you experienced something like "the Grand Redesign in the Sky" and how did that end?
4. What is / has been your explanation to having written bad code (as we all have done!) in the past?
5. Do you think it is suitable for us as a team to align to a "School Of Thoughts" (p12) or do you see any better path to having a more uniform clean code conception?
6. What do you think of "the Boy Scout Rule" (p.14) applied to code?
7. Are you familiar with any or all following Principles of Design (S.O.L.I.D.) (p15):
   • SRP - The Single Responsibility Principle
   • OCP - The Open / Closed Principle
   • LSP - The Liskov Substitution Principle
   • ISP - The Interface Segration Principle
   • DIP - The Dependency-Inversion Principle
8. What do you think is the status of Clean Code at our company?

As a side-note, Robert C. Martin and Joel Spolsky, the two people basically mentioned above, seem to be disagreeing a lot these days (excellent summary here by Niclas Nilsson). I guess they have not read my writing upon the Truth vs the Truth... They seem to have made up somewhat in the end though.

Reading the Clean Code book, as for reading any book really, is not just about reading and understanding. It is also about reflecting on what is stated and translate it into your own context and experience. I hope that these questions will help you do this.  

In a previous post entry I wrote about my idea of starting a Clean Code study circle at work. In this blog post I will collect an overview of the book as we continue our study circle providing links to blog post containing questions for each chapter. I've also posted some guidelines and recommendations for others who are thinking of starting a study circle. I will be updating the list below with links as we go along with our study circle at Admeta during 2009.

Study Questions chapter overview

1. Clean Code: questions
2. Meaningful names: questions
3. Functions: questions
4. Comments: questions
5. Formatting: questions
6. Objects and Data Structures
7. Error Handling
8. Boundaries
9. Unit Tests
10. Classes
11. Systems
12. Emergence
13. Concurrency
14. Successive Refinement
15. JUnit Internals
16. Refactoring Serial Date

Some Guidelines for Starting a Study Circle

If you are thinking of starting a study circle at work, here’s a couple of practical advises based upon our experience:

1. The topics in each chapter can potentially lead to discussion that lasts for days... But try to limit yourself to the time set out for it. The meetings is not necessarily about reaching a final agreement of every discussion. Instead, look at is as the beginning of a journey to some kind of agreement of a mutual understanding of what clean code is.
   
   
2. During the hour, we summarize each sub chapter. I.e. some volunteer person for each subchapter summarizes in his own word briefly and objectively what was written. Once done with this, the same person gets to be the first to reflect upon the content. A discussion can follow afterwards.
   
   For us, such a summary/discussion of the chapter would take more than an hour (in both groups). So it is a good idea to tell people in advance what subchapters they think should be focused on in each chapter. Start with these subchapters when you meet!
   
   Most likely, you will not have time to discuss the questions. But you may sneak a question in at a sub chapter discussion.
   
   
3. As a follow up to the meeting, use some kind of survey tool to poll questions discussed in the meetings. This way you will actually get a statistical backing up of what people think based not only by those who are the most eloquent with words.
   
   I tried out using SharePoint surveys but I don’t like the tool. (I might come back with a little blog post rant on this…)
   
   
4. If there are many developers, split the group into smaller groups. It is easier for all people to get a chance to say something if the groups are smaller. The person who set up the group will participate in both groups and act as the meeting coordinator and bridge between the two groups.
   
   If several groups are used, I think it is a good idea to rotate the people in it every other or third meeting. Everyone should really know everyone in good working teams.