checking in
This commit is contained in:
		
							
								
								
									
										30
									
								
								content/blog/boolean_names.md
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										30
									
								
								content/blog/boolean_names.md
									
									
									
									
									
										Normal file
									
								
							@@ -0,0 +1,30 @@
 | 
				
			|||||||
 | 
					---
 | 
				
			||||||
 | 
					img: /img/settings.png
 | 
				
			||||||
 | 
					title: "Boolean Variable Names"
 | 
				
			||||||
 | 
					author: Jeff Russo
 | 
				
			||||||
 | 
					pdate: FILL_IN_DATE
 | 
				
			||||||
 | 
					desc: Choosing a good boolean variable name
 | 
				
			||||||
 | 
					---
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					Choosing good names for variable is important.  They are a form of documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code.  Using a bad name for a variable leads to confusion, bugs, and wasted engineer time.  In this blog post I will discuss what makes a variable name good or bad, for [booleans](https://en.wikipedia.org/wiki/Boolean_data_type) in particular.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					## Purpose
 | 
				
			||||||
 | 
					A boolean's purpose is to toggle between true and false.  Therefore, the name should represent something that is true or false. 
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					## Good Boolean Names
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					## Bad Boolean Names
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					Variable names for booleans: avoid names that are already a negation (notReady, headless).
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					find examples in OSS (Gitea notify)
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					Read PoP and PoSD for bool blog post
 | 
				
			||||||
 | 
					Use an unambiguously negatable name.  No context should be needed for understanding.  Ex: “FlexibleName”
 | 
				
			||||||
 | 
					Going between configs is problematic. Ex: confA.UseProd = !confB.NoProd
 | 
				
			||||||
 | 
					Should be in the affirmative (useProd, not noProd)
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					answerable with yes or no (true or false)
 | 
				
			||||||
		Reference in New Issue
	
	Block a user