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?
I write C++ in paragraph.
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
For me, this is hard to read and maintain.
I'd rather be phishing!
-
I write C++ in paragraph.
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
For me, this is hard to read and maintain.
I'd rather be phishing!
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.
-
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 try to write all my code with maintenance in mind, versus trying to get everything on one bloody line. Just saying... :)
-
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'm the only one who has to read it, so I use a lot of white space, then I have room to make notes after I print it out.
IThing foo = new MyThing
(
"foo"
)
{
Size = new Size ( 50 )
} ;Sometimes I'll organize a group of similar things horizontally so it's more obvious that they are similar:
IThing foo = new MyThing ( "foo" ) { Size = new Size ( 50 ) } ;
IThing bar = new MyThing ( "bar" ) { Size = new Size ( 50 ) } ;
IThing baz = new MyThing ( "baz" ) { Size = new Size ( 50 ) } ;But that can hit my line limit (112 characters) pretty quick.
-
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?
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 :)
-
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 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
-
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?
When I look at some code, I wonder which paragraphs of the law may apply and what the author should be sentenced to. Before someone screams at me for not being on topic enough: I don't have much of a choice right now.
SUM_Loop: SEX R2
LDN R7 ; get a byte from the ROM
STXD ; push it onto the stack
IRX
GLO R8 ; get the low byte of the current sum
ADD ; add both bytes
PLO R8 ; update R8.0GHI R8 ; get the high byte of the current sum ADCI 00H ; add 00H with carry PHI R8 ; update R8.1 GHI R7 ; are we done? SDI HI(ROMEnd) BNZ SUM\_Continue GLO R7 SDI HI(ROMEnd) BZ SUM\_ResultI have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
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?
Some set of unwritten rules in my head - taking into account any possibility of expansion down the line (keep it verbose) or none (one-liners). For example: The target of a php AJAX call will check for values:
$value = (isset($_REQUEST['value']))?$_REQUEST['value']:some_default;
as there's no where to go with this. On the other hand, an if/else block leaves easy room for expansion - unless, of course, it's amenable to a switch(). And so on.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
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 also like each chained call on a new line:
List
.WhenNotEmpty()?
.ForEach(s => s.Prepare(out var r)?
.Manipulate(r));This code, however raises red flags when if I were to review it:
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
Seeing an "out" var inside a ForEach, then doing something with the value smells of side-effects. I know this is a contrived example, but if I saw this, I would take some time to investigate and possibly suggest a way of encapsulating it in a method and ensure no side effects can leak out, or encapsulate the state changes in a return object so it is obvious.
-
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 :)
I'll use that format too, or use parens like braces. Sometimes I'll put my conditionals on the next line. Sometimes it seems clearer. But not always. This tells me a lot but is really hard to read.
list
.WhenNotEmpty()
?.ForEach(
s => s.Prepare(out var r)
?.Manipulate(r)
);I should be consistent... :sigh: The analogy was a little loose. Maybe bullets and paragraphs would be better. Overall I kind-of missed the mark. Basically, when I'm reading code and have to scroll through many lines of code my mind goes to the details of the code and not the business flow. I like a style that favors "what it does" to "how it does it".
-
I also like each chained call on a new line:
List
.WhenNotEmpty()?
.ForEach(s => s.Prepare(out var r)?
.Manipulate(r));This code, however raises red flags when if I were to review it:
list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));
Seeing an "out" var inside a ForEach, then doing something with the value smells of side-effects. I know this is a contrived example, but if I saw this, I would take some time to investigate and possibly suggest a way of encapsulating it in a method and ensure no side effects can leak out, or encapsulate the state changes in a return object so it is obvious.
Yeah, I knew that bit would trigger a few shudders and cringes going in. Not something I would actually do, just felt a little impish when building the example...
-
I try to write all my code with maintenance in mind, versus trying to get everything on one bloody line. Just saying... :)
Yeah, agree. It has limited use. Mostly I'll do it during clean-up in top-level business methods when I'm trying to communicate complex business logic. I think it is slightly different than some one-liners of low-level code. Each "word" should be closer to a business activity than a data function. The "sentence" should be close to a business process step.
-
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?
Sentences. I use Linq, extension methods, and fluent style, meaning methods often return
thisrather than a value, which can be accessed through a getter property if necessary. And tuples! I love tuples! Again, a useful, common to other languages not just C#, that the juniors have never seen. The result looks a lot more like F# with its continuation and partial closure syntax. Sadly, even though the code "reads" easily enough, it boggles the mind of the junior devs. And the really sad thing is, the junior devs don't even know about the null continuation operator, so the first question I get is, WTF is?.As per my previous post, there's dumbing down, and then there's just lobotomy dumb. The null continuation operator is such a nice shorthand vs. cluttering code with if-else statements. So you'll see a lot of my code that looks likeGetXmlElement(Constants.MyElement)?.Value ?? Constants.MyElementDefaultValue);but again, the junior devs are totally flustered by the?. ??notation. Oh well, they need to learn. This notation (or equivalent) is common enough in other languages nowadays, so LEARN, GFD!!!! [edit]And worse, the juniors have never been mentored to NOT code literal strings, so their code is littered with literals. X| And of course, when something needs changing, you have to search the entire code base for all references. X| X| [edit] For example, I find this totally readable:new List<Control>() { tbCashDrawerOnes, tbCashDrawerTwos, tbCashDrawerFives, tbCashDrawerTens, tbCashDrawerTwenties, tbCashDrawerFifties, tbCashDrawerHundreds }.ForEach(ctrl => ctrl.TextChanged += (\_, \_\_) => ignoreCashDrawerTextBoxEvents.Else(() => UpdateCashDrawer()));But it is esoteric, I suppose.
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
-
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.
