Skip to main content

Timeline for Consecutive whitespace reduction

Current License: CC BY-SA 3.0

10 events
when toggle format what by license comment
Feb 2, 2016 at 19:10 comment added Avenicci Camel case for fields avoids ambiguity with class names and properties, that may be the most realistic reason to use it. Besides, it hints to the significance of the addressed identifier.
Feb 2, 2016 at 18:52 comment added Shelby115 @Avenicci For the naming, I would suggest a simple WhiteSpaceCompressor. I capitalized the 'S' to match Microsoft casing in the System.String.IsNullOrWhiteSpace() function.
Feb 2, 2016 at 18:50 comment added Shelby115 @Avenicci As for the Casing suggestion, I personally stand by making members Pascal. I looked it up and apparently Microsoft suggests camel-casing for Fields. The way I see it is a choice between more easily noticing the difference between a Property vs Field or more easily noticing Scope differences. In my experiences, the latter is more important to me.
Feb 2, 2016 at 18:48 comment added Shelby115 @Avenicci Ah, I was mistaken on your usage of Compress for the StringBuilder suggestion. Perhaps this points out how helpful comments can be.
Feb 2, 2016 at 18:40 comment added Avenicci Casing - Note that Seperator is a constant field, unlike builder. For constants, pascal case is the most conventional.
Feb 2, 2016 at 18:40 comment added Avenicci StringBuilder - This benefit only applies for the first string, after that, Compress remains cluttered with a null check. It is better to use StringBuilder.EnsureCapacity, although the benefit is futile in practice.
Feb 2, 2016 at 18:40 comment added Avenicci Naming - The name TextCompressor is highly ambiguous, though it was the most sensical name I encountered.
Feb 2, 2016 at 18:35 history edited Mathieu Guindon CC BY-SA 3.0
added 12 characters in body
Feb 2, 2016 at 18:33 history edited Shelby115 CC BY-SA 3.0
Fixed code formatting.
Feb 2, 2016 at 18:19 history answered Shelby115 CC BY-SA 3.0