Do you Program in Paragraphs or Sentences?
-
I think the difference is in debugging. If there is an error in your "Sentence" code, the debugger stops at that line and you have at least 5 points of failure on that line to check. You might end up turning it back into a paragraph before you figure it out. With the "paragraph", the debugger stops at the specific line with the error. I usually prefer the paragraph method, for that reason.
Brent
dbrenth wrote:
I think the difference is in debugging.
This is true. Happily the VS2017 debugger is much better (than previous versions of VS) about being able to step into (and even set breakpoints on) anonymous methods. The problem I tend to encounter with complex lambda expressions is, one misplaced , or paren or other typo and the whole expression syntax-errors with really no clue as to what the parser is actually annoyed about.
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?
Technically:
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));Would work as well as:list.ForEach(s => s.Prepare(out var r)?.Manipulate(r));Given that an empty list is, well, empty. But again, to rant more about junior devs vs. experienced devs, IMO (as an experienced dev) a list should never be null. It should be empty or have content. But I see so many "if null" checks because nobody initializes their collections in the constructor, for example. And since the juniors are stuck in the dark ages because they don't get training, even:list?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));is unknown to them, though I'd still squawk at them for having a null list. Then again, I've also seen the null continuation operator abused in ways that tell me the programmer really had no right to be writing code: [Code Review - What You Can Learn From a Single Line of Code](https://www.codeproject.com/Articles/1223338/Code-Review-What-You-Can-Learn-From-a-Single-Line)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
-
Personally, when chaining method calls, I like the LINQ convention of each method call in the chain on a separate line. So the following, from your example:
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
Becomes:
list
.WhenNotEmpty()?
.ForEach(s => s
.Prepare(out var r)?
.Manipulate(r));Might just be me, but I find it easier to read that way. That said, not sure I completely follow the sentence / paragraph analogy :)
Eric Lynch wrote:
Might just be me,
I do it too.
-
Technically:
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));Would work as well as:list.ForEach(s => s.Prepare(out var r)?.Manipulate(r));Given that an empty list is, well, empty. But again, to rant more about junior devs vs. experienced devs, IMO (as an experienced dev) a list should never be null. It should be empty or have content. But I see so many "if null" checks because nobody initializes their collections in the constructor, for example. And since the juniors are stuck in the dark ages because they don't get training, even:list?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));is unknown to them, though I'd still squawk at them for having a null list. Then again, I've also seen the null continuation operator abused in ways that tell me the programmer really had no right to be writing code: [Code Review - What You Can Learn From a Single Line of Code](https://www.codeproject.com/Articles/1223338/Code-Review-What-You-Can-Learn-From-a-Single-Line)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
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
-
Technically:
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));Would work as well as:list.ForEach(s => s.Prepare(out var r)?.Manipulate(r));Given that an empty list is, well, empty. But again, to rant more about junior devs vs. experienced devs, IMO (as an experienced dev) a list should never be null. It should be empty or have content. But I see so many "if null" checks because nobody initializes their collections in the constructor, for example. And since the juniors are stuck in the dark ages because they don't get training, even:list?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));is unknown to them, though I'd still squawk at them for having a null list. Then again, I've also seen the null continuation operator abused in ways that tell me the programmer really had no right to be writing code: [Code Review - What You Can Learn From a Single Line of Code](https://www.codeproject.com/Articles/1223338/Code-Review-What-You-Can-Learn-From-a-Single-Line)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
Interesting comment. I was returning the null to abuse the nullco and short circuit the chain, even though the (actual) list itself isn't null, just empty. But you make a good point about things that shouldn't be null. Returning a null when empty does (though only shortly until the nullco) create a null list. Not using the nullco immediately after would turn a null list loose.
-
Maintenance can definitely be harder. Sometimes when I do it this way I have to expand the code to debug and then collapse it back down. I think reading it is a little like shorthand. Once you get used to it, you get a lot of information in a small package.
I'm with Slacker on this, maintenance is the highest cost of software, make it readable and as simple as possible. Spell it out, let me know why you did something not just what you did. Convoluted, over engineered code is a nightmare for someone else to work with.
Never underestimate the power of human stupidity RAH
-
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 coding style sucks.
-
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 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 your example:
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
The WhenNotEmpty()?. isn't really needed, is it?
-
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 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?
I prefer funnels ;P [Modern Art: The Funnel - The Daily WTF](https://thedailywtf.com/articles/modern-art-the-funnel)
-
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?
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
-
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.
