Do you Program in Paragraphs or Sentences?
-
This was inspired by Marc Clifton's post [Dumbing down code so it can be maintained by junior devs](https://www.codeproject.com/Lounge.aspx?fid=1159&fr=126#xx0xx) I'm a horizontal programmer. I write chainable methods with (short) descriptive names. The top of my methods usually consists of a few "sentences" composed of these "words". If I can put my code on one line, (braces, etc.) I usually do. Eg, simple method:
// Not me
string Foo(int x)
{
if(x == 1)
{
return "one";
}
else
{
return "not one";
}
}
}// sometimes me
string Foo(int x){
if (x == 1) {
return "one";
} else {
return "not one";
}
}// usually me
string Foo(int x) => (x == 1) ? "one" : "not one";// often me
string Foo(this int x) => (x == 1) ? "one" : "not one";I do things like this. (Not really this weird though :)).
public static List WhenNotEmpty(this List item) => (item.Count > 0) ? item : null;
public static string Prepare(this string item, out string prepared) => ((prepared = item + "Appended") == "HelloAppended") ? "ok" : null ;
public static void Manipulate(this string item, string stuff) => Debug.WriteLine($"{item}:{stuff}");So I can write in sentences
var list = new List {"a", "Hello", "c"};
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
Instead of paragraphs. (something like (methods would be a little different))
var list = new List {"a", "Hello", "c"};
if(list.count > 0){
foreach(var i in list){
var (condition, temp) = Prepare(i);
if(condition != null){
Manipulate(temp);
}
}
}Getting to the point, (finally :zzz: ) The paragraphs approach is clearer at the micro level (the details are clear), but the sentences is clearer at the macro level (the overall intent is clear). Of course you can wrap this paragraph in a method. But when you don't: Do you tend to write more at the macro/sentence level or micro/paragraph level?
This I can parse and validate, at a glance, without trying:
string Foo(int x)
{
if(x == 1)
{
return "one";
}
else
{
return "not one";
}
}
}This requires me to actually read the words on screen and consciously think about them:
string Foo(this int x) => (x == 1) ? "one" : "not one";
It's not "more clear" on a macro level. It's "more clear" to you personally. If you were one of my juniors, I'd reprimand you for using an esoteric personal style at work. If you were a senior colleague, I'd just skip all formalities and just stab you with a kitchen knife. :)
-
missing a close brace in your first // sometimes me example. and yeah, sometimes I do the same with similar (obvious) crap.
This internet thing is amazing! Letting people use it: worst idea ever!
Lopatir wrote:
missing a close brace in your first // sometimes me example.
Definitely me sometimes. :laugh:
It was broke, so I fixed it.
-
In your example:
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
The WhenNotEmpty()?. isn't really needed, is it?
No, not really in this case. Something like `.When(predicate)` that might have been better. Or following it with something where it did matter.
-
No, not really in this case. Something like `.When(predicate)` that might have been better. Or following it with something where it did matter.
I was saying that you can use an empty collection with foreach, which will basically do nothing. You shouldn't need anything there.
-
I was saying that you can use an empty collection with foreach, which will basically do nothing. You shouldn't need anything there.
Right. That's what I meant by "following it with something that did matter".
-
Marc Clifton wrote:
a list should never be null
There's one feature of C# 8 you'll like, then! :) csharplang/nullable-reference-types.md at master · dotnet/csharplang · GitHub[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
There's one feature of C# 8 you'll like, then!
Quite so. Still, I wonder where they're going with this -- nullable value types are great, and so it makes sense that the complement, non-nullable reference types, should exist, it certainly provides symmetry. But oh boy, there are going to be thousands of warnings in the code base I work with at work when (if ever) they opt-in for this. But it'll probably be a few years before they get their build systems onto the C# 8, which by then they still will probably be several versions behind, as they are now. :^)
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
This was inspired by Marc Clifton's post [Dumbing down code so it can be maintained by junior devs](https://www.codeproject.com/Lounge.aspx?fid=1159&fr=126#xx0xx) I'm a horizontal programmer. I write chainable methods with (short) descriptive names. The top of my methods usually consists of a few "sentences" composed of these "words". If I can put my code on one line, (braces, etc.) I usually do. Eg, simple method:
// Not me
string Foo(int x)
{
if(x == 1)
{
return "one";
}
else
{
return "not one";
}
}
}// sometimes me
string Foo(int x){
if (x == 1) {
return "one";
} else {
return "not one";
}
}// usually me
string Foo(int x) => (x == 1) ? "one" : "not one";// often me
string Foo(this int x) => (x == 1) ? "one" : "not one";I do things like this. (Not really this weird though :)).
public static List WhenNotEmpty(this List item) => (item.Count > 0) ? item : null;
public static string Prepare(this string item, out string prepared) => ((prepared = item + "Appended") == "HelloAppended") ? "ok" : null ;
public static void Manipulate(this string item, string stuff) => Debug.WriteLine($"{item}:{stuff}");So I can write in sentences
var list = new List {"a", "Hello", "c"};
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
Instead of paragraphs. (something like (methods would be a little different))
var list = new List {"a", "Hello", "c"};
if(list.count > 0){
foreach(var i in list){
var (condition, temp) = Prepare(i);
if(condition != null){
Manipulate(temp);
}
}
}Getting to the point, (finally :zzz: ) The paragraphs approach is clearer at the micro level (the details are clear), but the sentences is clearer at the macro level (the overall intent is clear). Of course you can wrap this paragraph in a method. But when you don't: Do you tend to write more at the macro/sentence level or micro/paragraph level?
Your first example has one great advantage: When your productivity is measured in number of code lines produced, it wins by a large margin. The disadvantage is that to get an overview over even a fairly trivial function that really should fit in a screenful, you have to flip back and forth though a pile of pages. In any sufficiently fancy editor you can split the window so you can correlate various parts of the function logic, but then you can fit half as much logic in each tile, and that may be too little! A second disadvantage: With all that whitespace (frequently, programmers add at least one blank line before and after every loop, after function initialization, ... everywhere!), you have to look really close to see where this function ends and the next function starts. Except that those blank line lovers usually also add a huge comment block before every function to explain that ThePriceOfApplesPerKilogram argument is the price of apples per kilogram, that pi has the value of 3.1415926535897932384626433 and similar essential information. To some of these programmers, "readability" is a synonym for "whitespace percentage". Sort of homeopathic programming: The more diluted, the more powerful. On the other hand: The APL ideal of "There is no programming task so complex that it cannot be solved in a single line of APL" goes too far for my taste. An example from Wikipedia -The game of Life: life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵} I put most regex in the same category. Geek & Poke: Yesterday's regex[^] I'd like to place myself in the middle of the road, but I cannot deny that those homeopatic programmers raises such protests in me that I lean somewhat over to the other side. If you cannot fit every function in its entirety on a single screenful, then you have used too much whitespace.
-
This I can parse and validate, at a glance, without trying:
string Foo(int x)
{
if(x == 1)
{
return "one";
}
else
{
return "not one";
}
}
}This requires me to actually read the words on screen and consciously think about them:
string Foo(this int x) => (x == 1) ? "one" : "not one";
It's not "more clear" on a macro level. It's "more clear" to you personally. If you were one of my juniors, I'd reprimand you for using an esoteric personal style at work. If you were a senior colleague, I'd just skip all formalities and just stab you with a kitchen knife. :)
Do you really have parsing problems with
string Foo(int x) {
if (x == 1) return "one";
else return "not one";
}This style gives me a third as many source "code lines" to relate to. I can easily overview the entire function. In a larger function, a less whitespaced layout makes it much easier to spot the start/end of loops and condition blocks etc.
-
The one problem I have with the everything-on-one-line approach style of programming (which I also do a lot) is that it's impossible to debug. You don't get intermediate values and you don't get to set breakpoints at specific functions. The readability aspect is not that big of a deal, I can read it just fine (usually). However, since you write code only once and read and debug it a gazillion times I prefer to write my code so I can step through it. Sometimes I put it back together for readability afterwards. For example:
// Debuggable
var filtered = myList.Where(...);
var ordered = filtered.OrderBy(...);
var result = ordered.ToList();
return result;// Readable
return myList
.Where(...)
.OrderBy(...)
.ToList();Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
All that depends on the debugger. E.g. in Visual Studio, if you write your code as
string Foo(int x) {
if (x == 1) return "one";
else return "not one";
}and you only want to break when "one" is returned, mark the statement return "one"; with the mouse and hit F9. It will not break for the "if" tests, but only if the true branch is taken.
-
All that depends on the debugger. E.g. in Visual Studio, if you write your code as
string Foo(int x) {
if (x == 1) return "one";
else return "not one";
}and you only want to break when "one" is returned, mark the statement return "one"; with the mouse and hit F9. It will not break for the "if" tests, but only if the true branch is taken.
Yeah, but I believe that's a new feature since VS2017 :) Just like you can now debug in-line lambda's. It wasn't always like that (and still sometimes isn't).
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I prefer funnels ;P [Modern Art: The Funnel - The Daily WTF](https://thedailywtf.com/articles/modern-art-the-funnel)
IOCCC, the International Obfuscated C Code Contest (International Obfuscated C Code Contest [^]) often have some beauties, not only in obfuscatedness but also in code layout.
-
This was inspired by Marc Clifton's post [Dumbing down code so it can be maintained by junior devs](https://www.codeproject.com/Lounge.aspx?fid=1159&fr=126#xx0xx) I'm a horizontal programmer. I write chainable methods with (short) descriptive names. The top of my methods usually consists of a few "sentences" composed of these "words". If I can put my code on one line, (braces, etc.) I usually do. Eg, simple method:
// Not me
string Foo(int x)
{
if(x == 1)
{
return "one";
}
else
{
return "not one";
}
}
}// sometimes me
string Foo(int x){
if (x == 1) {
return "one";
} else {
return "not one";
}
}// usually me
string Foo(int x) => (x == 1) ? "one" : "not one";// often me
string Foo(this int x) => (x == 1) ? "one" : "not one";I do things like this. (Not really this weird though :)).
public static List WhenNotEmpty(this List item) => (item.Count > 0) ? item : null;
public static string Prepare(this string item, out string prepared) => ((prepared = item + "Appended") == "HelloAppended") ? "ok" : null ;
public static void Manipulate(this string item, string stuff) => Debug.WriteLine($"{item}:{stuff}");So I can write in sentences
var list = new List {"a", "Hello", "c"};
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
Instead of paragraphs. (something like (methods would be a little different))
var list = new List {"a", "Hello", "c"};
if(list.count > 0){
foreach(var i in list){
var (condition, temp) = Prepare(i);
if(condition != null){
Manipulate(temp);
}
}
}Getting to the point, (finally :zzz: ) The paragraphs approach is clearer at the micro level (the details are clear), but the sentences is clearer at the macro level (the overall intent is clear). Of course you can wrap this paragraph in a method. But when you don't: Do you tend to write more at the macro/sentence level or micro/paragraph level?
This is the first time I have seen "this" being used to prefix a parameter, and Googling doesn't find it. Could you explain, please?
-
This is the first time I have seen "this" being used to prefix a parameter, and Googling doesn't find it. Could you explain, please?
Check out [Extension Methods (C# Programming Guide) | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods)
-
Do you really have parsing problems with
string Foo(int x) {
if (x == 1) return "one";
else return "not one";
}This style gives me a third as many source "code lines" to relate to. I can easily overview the entire function. In a larger function, a less whitespaced layout makes it much easier to spot the start/end of loops and condition blocks etc.
I can parse it line by line at a normal reading speed. Takes about 3-4 seconds the first time I see it. The initial style I can parse and verify without having to read a single word. Takes me about 250 milliseconds. The benefit of having spacious functions is that mistakes become embarrassingly easy to spot. Likewise, properly written functions become very easy to parse, because they look so damn familiar. I find "less lines of code" a dubious benefit. A cramped style is more time-consuming to debug, both in terms of setting breakpoints and retracing logged exceptions. Also, I definitely agree functions should not grow too big.. but stacking multiple logical steps on a single line only gives you the illusion of small functions. I say: be spacious, let functions grow, and flag them for refactoring if they don't fit on a single page. The point is to write code that's self-evident +6 months in the future. Quick to read, amend and fix if need be.
-
This was inspired by Marc Clifton's post [Dumbing down code so it can be maintained by junior devs](https://www.codeproject.com/Lounge.aspx?fid=1159&fr=126#xx0xx) I'm a horizontal programmer. I write chainable methods with (short) descriptive names. The top of my methods usually consists of a few "sentences" composed of these "words". If I can put my code on one line, (braces, etc.) I usually do. Eg, simple method:
// Not me
string Foo(int x)
{
if(x == 1)
{
return "one";
}
else
{
return "not one";
}
}
}// sometimes me
string Foo(int x){
if (x == 1) {
return "one";
} else {
return "not one";
}
}// usually me
string Foo(int x) => (x == 1) ? "one" : "not one";// often me
string Foo(this int x) => (x == 1) ? "one" : "not one";I do things like this. (Not really this weird though :)).
public static List WhenNotEmpty(this List item) => (item.Count > 0) ? item : null;
public static string Prepare(this string item, out string prepared) => ((prepared = item + "Appended") == "HelloAppended") ? "ok" : null ;
public static void Manipulate(this string item, string stuff) => Debug.WriteLine($"{item}:{stuff}");So I can write in sentences
var list = new List {"a", "Hello", "c"};
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
Instead of paragraphs. (something like (methods would be a little different))
var list = new List {"a", "Hello", "c"};
if(list.count > 0){
foreach(var i in list){
var (condition, temp) = Prepare(i);
if(condition != null){
Manipulate(temp);
}
}
}Getting to the point, (finally :zzz: ) The paragraphs approach is clearer at the micro level (the details are clear), but the sentences is clearer at the macro level (the overall intent is clear). Of course you can wrap this paragraph in a method. But when you don't: Do you tend to write more at the macro/sentence level or micro/paragraph level?
Paragraph level. Are you thinking that the compiler does something more optimized because you wrote it as a sentence instead of paragraph? Or were you thinking that less typing benefits the project overall? Or perhaps some other underlying reason? Paragraph style is not only more readable and understandable to another programmer reading it for the first time, it is more readable and understandable to you 6 months, a year, or 2 years later when you revisit the code for the first time since you finished it. Paragraph style is also easier to debug and see runtime values. When you are not the only programmer involved now or conceivably in the future, paragraph style would have a positive effect on the maintenance portion of lifecycle cost. Another benefit of paragraph style is that it lends itself better to adding comments that explain the what and why of what you are doing.
-
Check out [Extension Methods (C# Programming Guide) | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods)
Thanks, I think. ;-}
-
This was inspired by Marc Clifton's post [Dumbing down code so it can be maintained by junior devs](https://www.codeproject.com/Lounge.aspx?fid=1159&fr=126#xx0xx) I'm a horizontal programmer. I write chainable methods with (short) descriptive names. The top of my methods usually consists of a few "sentences" composed of these "words". If I can put my code on one line, (braces, etc.) I usually do. Eg, simple method:
// Not me
string Foo(int x)
{
if(x == 1)
{
return "one";
}
else
{
return "not one";
}
}
}// sometimes me
string Foo(int x){
if (x == 1) {
return "one";
} else {
return "not one";
}
}// usually me
string Foo(int x) => (x == 1) ? "one" : "not one";// often me
string Foo(this int x) => (x == 1) ? "one" : "not one";I do things like this. (Not really this weird though :)).
public static List WhenNotEmpty(this List item) => (item.Count > 0) ? item : null;
public static string Prepare(this string item, out string prepared) => ((prepared = item + "Appended") == "HelloAppended") ? "ok" : null ;
public static void Manipulate(this string item, string stuff) => Debug.WriteLine($"{item}:{stuff}");So I can write in sentences
var list = new List {"a", "Hello", "c"};
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
Instead of paragraphs. (something like (methods would be a little different))
var list = new List {"a", "Hello", "c"};
if(list.count > 0){
foreach(var i in list){
var (condition, temp) = Prepare(i);
if(condition != null){
Manipulate(temp);
}
}
}Getting to the point, (finally :zzz: ) The paragraphs approach is clearer at the micro level (the details are clear), but the sentences is clearer at the macro level (the overall intent is clear). Of course you can wrap this paragraph in a method. But when you don't: Do you tend to write more at the macro/sentence level or micro/paragraph level?
In our world, and our code reviews, this one line stuff has to go. The coding standards should dictate the formatting. BUT: The Situation can dictate exceptions. We have defensible and in-defensible deviations. Blocks of similar code where reading one line is effectively the same in the block, we allow the one line to create a "tabular" view of what is transpiring. BTW, I don't consider breaking down the code into properly formatted statements to be dumbing down the code. I also think that different companies CAN AND SHOULD have different coding standards! But overall, I believe if you can pick up a piece of code, and not know if YOU wrote it, or someone else on your team wrote it... Then you are cooking with gas.
-
This was inspired by Marc Clifton's post [Dumbing down code so it can be maintained by junior devs](https://www.codeproject.com/Lounge.aspx?fid=1159&fr=126#xx0xx) I'm a horizontal programmer. I write chainable methods with (short) descriptive names. The top of my methods usually consists of a few "sentences" composed of these "words". If I can put my code on one line, (braces, etc.) I usually do. Eg, simple method:
// Not me
string Foo(int x)
{
if(x == 1)
{
return "one";
}
else
{
return "not one";
}
}
}// sometimes me
string Foo(int x){
if (x == 1) {
return "one";
} else {
return "not one";
}
}// usually me
string Foo(int x) => (x == 1) ? "one" : "not one";// often me
string Foo(this int x) => (x == 1) ? "one" : "not one";I do things like this. (Not really this weird though :)).
public static List WhenNotEmpty(this List item) => (item.Count > 0) ? item : null;
public static string Prepare(this string item, out string prepared) => ((prepared = item + "Appended") == "HelloAppended") ? "ok" : null ;
public static void Manipulate(this string item, string stuff) => Debug.WriteLine($"{item}:{stuff}");So I can write in sentences
var list = new List {"a", "Hello", "c"};
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
Instead of paragraphs. (something like (methods would be a little different))
var list = new List {"a", "Hello", "c"};
if(list.count > 0){
foreach(var i in list){
var (condition, temp) = Prepare(i);
if(condition != null){
Manipulate(temp);
}
}
}Getting to the point, (finally :zzz: ) The paragraphs approach is clearer at the micro level (the details are clear), but the sentences is clearer at the macro level (the overall intent is clear). Of course you can wrap this paragraph in a method. But when you don't: Do you tend to write more at the macro/sentence level or micro/paragraph level?
Quote:
string Foo(int x){ if (x == 1) { return "one"; } else { return "not one"; } }
string Foo(int x) { return x == 1 ? "one" : "not one"; }
(I also tend to twitch when I see a "return" followed by an "else".)
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
Paragraph level. Are you thinking that the compiler does something more optimized because you wrote it as a sentence instead of paragraph? Or were you thinking that less typing benefits the project overall? Or perhaps some other underlying reason? Paragraph style is not only more readable and understandable to another programmer reading it for the first time, it is more readable and understandable to you 6 months, a year, or 2 years later when you revisit the code for the first time since you finished it. Paragraph style is also easier to debug and see runtime values. When you are not the only programmer involved now or conceivably in the future, paragraph style would have a positive effect on the maintenance portion of lifecycle cost. Another benefit of paragraph style is that it lends itself better to adding comments that explain the what and why of what you are doing.
When I started I was actually thinking more about separating concepts and mechanics, or maybe better, business vs technology. But I think I lost that some when playing with creating my examples. ) In business applications (vs scientific/engineering) most methods implement some part of a business function. At an absurdum extreme you could write the application in one procedural block with thousands of lines of branching/conditional code, where each line does no more than a single thing. It contains an atomic concept. So, you wouldn't write `if(x == 1 || x == 3)`, that is two concepts. At this extreme, every atomic thought is crystal clear, but the big-picture of what the method does becomes a forest-trees thing. We decompose software into logical, understandably named chunks, like methods and classes. At another absurd extreme, we could make each concept a method - `bool IsValueEqualToOne(int x) {if x ==1 return true else return false}`. This is just as bad. We have only translated from a technical representation `(x == 1)?` to a business representation `IsValueEqualToOne`. In real-world programming we balance the size and form of our chunks. In some cases, it is better to combine at a "technical" level - `if(x == 1 || x == 3)`. In others, a business level is better
// transfer
if(AccountHasFunds(sourceAccount, amount)){
debit(sourceAccount, amount);
credit(targetAccount amount);
}At the opposite extreme or "can't see the forest for the trees" is "needle in a haystack", one liners. Like the examples I gave. ( and tried to disclaim as how I would actually do it. :) ) So, to your question
Quote:
compiler does something more optimized... Or perhaps some other underlying reason?
In rereading it sounds like I may be advocating "one-liners", but not really. All the LINQ and stuff has a greater chance of compiler confusion than optimization. Maybe the best I can think of is that each method we write contains a business purpose and a technical implementation. The clearest code communicates both, and the best code does this in a maintainable way. With LINQ style and functional becoming popular I was curious to see if people were writing more that way. My preferred method of coding combines approaches, made easier with local functions. (I just make up "transaction syntax for simplicity)
void TransferFunds(source, target, amount){
// Business - more compressed to highlight business logic
if(AccountHasF -
Quote:
string Foo(int x){ if (x == 1) { return "one"; } else { return "not one"; } }
string Foo(int x) { return x == 1 ? "one" : "not one"; }
(I also tend to twitch when I see a "return" followed by an "else".)
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
I've seen a lot of discussion lately about single point of exit vs multiple points of exit. Since my IDE makes them easy to spot I've started using multiples more in `if` and `switch`. But when I see the code in a plain text editor it still can look a little confusing.
