How do you write fewer lines of code?
-
Bassam Abdul-Baki wrote:
Using someone else's code is not technically reducing it.
I was wondering if someone would say that. Well, technically, it reduces the lines of "my" code. Otherwise, you would have to take this to the logical extremes of 1) any framework code + calls to Win API and 2) might as well reduce it to lines of code in the MSIL/assembly language. That doesn't make a lot of sense to me. Marc
-
It's just an example! :sigh:
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
From Mehdi's question about "is less lines of code better" -- Question: How do you go about writing fewer lines of code (omitting removing line breaks as an answer) ? One obvious answer is, replace redundant code with a function. Another possible answer is, using Linq to replace for-next loops (funny how we [well, I do] still call them for-next loops) One other answer to that comes to mind is using OOP to eliminate "if" statements regarding type. Anyways, that's my question--if you really want to achieve fewer lines of code but the same behavior, what really are good practices? Marc
Easy – you need to get smarter. This highly reduces LOC.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
From Mehdi's question about "is less lines of code better" -- Question: How do you go about writing fewer lines of code (omitting removing line breaks as an answer) ? One obvious answer is, replace redundant code with a function. Another possible answer is, using Linq to replace for-next loops (funny how we [well, I do] still call them for-next loops) One other answer to that comes to mind is using OOP to eliminate "if" statements regarding type. Anyways, that's my question--if you really want to achieve fewer lines of code but the same behavior, what really are good practices? Marc
Good design and reducing plumbing code more than anything. Nothing complicates an app and drives up the line count than fighting with an object model that doesn't match what you are trying to do with it. If you have to routinely make changes to multiple parts of your model that require complicated operations to connect, then you are going to write a bunch of extra code.
Curvature of the Mind now with 3D
-
From Mehdi's question about "is less lines of code better" -- Question: How do you go about writing fewer lines of code (omitting removing line breaks as an answer) ? One obvious answer is, replace redundant code with a function. Another possible answer is, using Linq to replace for-next loops (funny how we [well, I do] still call them for-next loops) One other answer to that comes to mind is using OOP to eliminate "if" statements regarding type. Anyways, that's my question--if you really want to achieve fewer lines of code but the same behavior, what really are good practices? Marc
I tend to collapse if/else statements. If there's just a single if/else, I'll use the (what's the name of this?) operator:
return foo ? "it was foo" : "it was not!";
For big if/elses, or switch statements, I use a custom extension method and type, loosely inspired by F#'s match expressions:
return answer
.Match(42, "It was 42!")
.Match(7, "Perfecttion!")
.Match(-1, () => throw new ArgumentException(...))
.DefaultTo("unknown!");I find that cleaner and more concise than big if/else or switch blocks.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
I tend to collapse if/else statements. If there's just a single if/else, I'll use the (what's the name of this?) operator:
return foo ? "it was foo" : "it was not!";
For big if/elses, or switch statements, I use a custom extension method and type, loosely inspired by F#'s match expressions:
return answer
.Match(42, "It was 42!")
.Match(7, "Perfecttion!")
.Match(-1, () => throw new ArgumentException(...))
.DefaultTo("unknown!");I find that cleaner and more concise than big if/else or switch blocks.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
Judah Himango wrote:
I use a custom extension method and type, inspired by F#'s match expressions:
Ooh, that's sweet! I remember encountering this a while ago, but I'm glad you reminded me. Marc
-
I tend to collapse if/else statements. If there's just a single if/else, I'll use the (what's the name of this?) operator:
return foo ? "it was foo" : "it was not!";
For big if/elses, or switch statements, I use a custom extension method and type, loosely inspired by F#'s match expressions:
return answer
.Match(42, "It was 42!")
.Match(7, "Perfecttion!")
.Match(-1, () => throw new ArgumentException(...))
.DefaultTo("unknown!");I find that cleaner and more concise than big if/else or switch blocks.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
That is sweet.
Curvature of the Mind now with 3D
-
From Mehdi's question about "is less lines of code better" -- Question: How do you go about writing fewer lines of code (omitting removing line breaks as an answer) ? One obvious answer is, replace redundant code with a function. Another possible answer is, using Linq to replace for-next loops (funny how we [well, I do] still call them for-next loops) One other answer to that comes to mind is using OOP to eliminate "if" statements regarding type. Anyways, that's my question--if you really want to achieve fewer lines of code but the same behavior, what really are good practices? Marc
Remove functionality that seemed a great idea at the time but simply results in an unused feature and a ton of code to support the plumbing.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Ahh yes. For me, there has to be more than two lines of code to make it worth it, and then you have to consider th4 amount of stack and heap manipulation involved in making the function call (if it's "redundant", it probably requires some sort of poarameter for the function, thus increasing stack usage) versus just leaving the code where it is. Like everything else in coding, there are trade-offs.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997you can eliminate the stack and heap overhead with function inlining.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
Close the IDE after the next semi-colon.
Marc Clifton wrote:
One obvious answer is, replace redundant code with a function.
But that's just writing the code somewhere else, so that doesn't count. There are no "good practices. You can eliminate error checking (bad practice), elminate line breaks (bad practice), or according to some start writing in VB (bad practice). This bizarre search for "less code" leads to the crap we get from Microsoft.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997John Simmons / outlaw programmer wrote:
This bizarre search for "less code" leads to the crap
not always. sometimes eliminating code also eliminates bugs and makes a product better
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
that's the whole point of this thread.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
From Mehdi's question about "is less lines of code better" -- Question: How do you go about writing fewer lines of code (omitting removing line breaks as an answer) ? One obvious answer is, replace redundant code with a function. Another possible answer is, using Linq to replace for-next loops (funny how we [well, I do] still call them for-next loops) One other answer to that comes to mind is using OOP to eliminate "if" statements regarding type. Anyways, that's my question--if you really want to achieve fewer lines of code but the same behavior, what really are good practices? Marc
Another way I write less code is by using the Reactive Extensions (Rx). Instead of events + properties + plumbing, you instead use System.IObservable<T> and Linq. So, instead of this:
// Old way of doing this
public class FileUpload : INotifyPropertyChanged
{
private string fileName;
private int progress;public event PropertyChangedEventHandler PropertyChanged; public event EventHandler UploadCompleted; public string FileName { get { return fileName; } set { if (fileName != value) { fileName = value; RaisePropertyChanged("FileName"); } } } public int Progress { get { return this.progress; } set { if (this.progress != value) { this.progress = value; RaisePropertyChanged("Progress"); if (value == 100) { if (UploadCompleted != null) { UploadCompleted(this, EventArgs.Empty); } } } } } private void RaisePropertyChanged(string propertyName) { if (PropertyChanged != null) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } }}
Instead you can write this:
// New way, courtesy of Rx
public class FileUpload
{
public IObservable Progress { get; }
public IObservable FileName { get; }
}Consumption:
// tell me when progress changes
fileUpload.Progress.Subscribe(p => Console.WriteLine("progress updated to " + p));// tell me when upload is done
fileUpload.Progress.Where(p => p == 100).Subscribe(p => Console.WriteLine("finished!"));My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
you could have used a static class to much the same effect.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
Another way I write less code is by using the Reactive Extensions (Rx). Instead of events + properties + plumbing, you instead use System.IObservable<T> and Linq. So, instead of this:
// Old way of doing this
public class FileUpload : INotifyPropertyChanged
{
private string fileName;
private int progress;public event PropertyChangedEventHandler PropertyChanged; public event EventHandler UploadCompleted; public string FileName { get { return fileName; } set { if (fileName != value) { fileName = value; RaisePropertyChanged("FileName"); } } } public int Progress { get { return this.progress; } set { if (this.progress != value) { this.progress = value; RaisePropertyChanged("Progress"); if (value == 100) { if (UploadCompleted != null) { UploadCompleted(this, EventArgs.Empty); } } } } } private void RaisePropertyChanged(string propertyName) { if (PropertyChanged != null) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } }}
Instead you can write this:
// New way, courtesy of Rx
public class FileUpload
{
public IObservable Progress { get; }
public IObservable FileName { get; }
}Consumption:
// tell me when progress changes
fileUpload.Progress.Subscribe(p => Console.WriteLine("progress updated to " + p));// tell me when upload is done
fileUpload.Progress.Where(p => p == 100).Subscribe(p => Console.WriteLine("finished!"));My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
Judah Himango wrote:
Another way I write less code is by using the Reactive Extensions (Rx)
Ah, you remind me that I need to learn more about Rx. Thank you! Marc
-
that's the whole point of this thread.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
Another way I write less code is by using the Reactive Extensions (Rx). Instead of events + properties + plumbing, you instead use System.IObservable<T> and Linq. So, instead of this:
// Old way of doing this
public class FileUpload : INotifyPropertyChanged
{
private string fileName;
private int progress;public event PropertyChangedEventHandler PropertyChanged; public event EventHandler UploadCompleted; public string FileName { get { return fileName; } set { if (fileName != value) { fileName = value; RaisePropertyChanged("FileName"); } } } public int Progress { get { return this.progress; } set { if (this.progress != value) { this.progress = value; RaisePropertyChanged("Progress"); if (value == 100) { if (UploadCompleted != null) { UploadCompleted(this, EventArgs.Empty); } } } } } private void RaisePropertyChanged(string propertyName) { if (PropertyChanged != null) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } }}
Instead you can write this:
// New way, courtesy of Rx
public class FileUpload
{
public IObservable Progress { get; }
public IObservable FileName { get; }
}Consumption:
// tell me when progress changes
fileUpload.Progress.Subscribe(p => Console.WriteLine("progress updated to " + p));// tell me when upload is done
fileUpload.Progress.Where(p => p == 100).Subscribe(p => Console.WriteLine("finished!"));My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
Say, has Rx always been a Microsoft thing? I thought it was developed by some other folks. Marc
-
Say, has Rx always been a Microsoft thing? I thought it was developed by some other folks. Marc
Yeah, always has been an Microsoft thing. I spoke with the authors of Rx this spring at the Mix conference. Very sharp guys. I asked them whether Rx will be merged into .NET framework proper. They responded that while they were considering it, they're leaning against it because it's entirely additive (LINQ over System.IObservable<T>), and that the core pieces of Rx (System.IObserver<T> and System.IObservable<T>) are already baked into the .NET framework. Anyways, very nifty framework that few know about.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
Close the IDE after the next semi-colon.
Marc Clifton wrote:
One obvious answer is, replace redundant code with a function.
But that's just writing the code somewhere else, so that doesn't count. There are no "good practices. You can eliminate error checking (bad practice), elminate line breaks (bad practice), or according to some start writing in VB (bad practice). This bizarre search for "less code" leads to the crap we get from Microsoft.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Line breaks made the code more readable. I don't think the elimination of line breaks should be a desired outcome. Code shouldn't be measured based on "# of lines". While reducing redundancy is desirable, the goal there is to increase maintainability, not to decrease the number of lines of code.
-
From Mehdi's question about "is less lines of code better" -- Question: How do you go about writing fewer lines of code (omitting removing line breaks as an answer) ? One obvious answer is, replace redundant code with a function. Another possible answer is, using Linq to replace for-next loops (funny how we [well, I do] still call them for-next loops) One other answer to that comes to mind is using OOP to eliminate "if" statements regarding type. Anyways, that's my question--if you really want to achieve fewer lines of code but the same behavior, what really are good practices? Marc
I find going to work works.
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
I tend to collapse if/else statements. If there's just a single if/else, I'll use the (what's the name of this?) operator:
return foo ? "it was foo" : "it was not!";
For big if/elses, or switch statements, I use a custom extension method and type, loosely inspired by F#'s match expressions:
return answer
.Match(42, "It was 42!")
.Match(7, "Perfecttion!")
.Match(-1, () => throw new ArgumentException(...))
.DefaultTo("unknown!");I find that cleaner and more concise than big if/else or switch blocks.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
I make extensive use of the ternary operator[^]. I also like your use of method chaining. My experience is that most peoples brains explode when they see such code.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
