Streamreader help C#

[Painey]

I want to read from the second line in a .txt file by using my streamread function.(creating a template for myself)

string line;
            
	StreamReader sr = new StreamReader("C:\\Users\\bayba\\Desktop\\Read.txt");

	line = sr.ReadLine();
    
    sr.Close();

    StreamWriter spw = new StreamWriter("C:\\Users\\bayba\\Desktop\\Write.txt");

	spw.WriteLine(line);

    spw.Close();

I already know how to read from the first line, is there any way i can read from the second without having to do too much work?

[Murasaki]

Spoiler

string GetLine(string fileName, int line)
{
   using (var sr = new StreamReader(fileName)) {
       for (int i = 1; i < line; i++)
          sr.ReadLine();
       return sr.ReadLine();
   }
}

This is what you're probably looking for.

No code button on my phone so spoiler it is.

[Nuluvius]

You can avoid using the StreamReader entirely if you like:

var line = File.ReadLines("SomeFile.txt").Skip(1).Take(1).First();

[Painey]

3 minutes ago, Nuluvius said:

You can avoid using the StreamReader entirely if you like:

var line = File.ReadLines("SomeFile.txt").Skip(1).Take(1).First();

Would i still be able to use my streamwriter afterwards if i use this?

[Yamoto42]

6 minutes ago, Painey said:

Would i still be able to use my streamwriter afterwards if i use this?

There is no reader or writer [visibly] involved in that solution.  You are perfectly free to make one if you so wish.

[Nuluvius]

7 minutes ago, Painey said:

Would i still be able to use my streamwriter afterwards if i use this?

You can do whatever you like its your application 

 

You might like to have a look at File.WriteAllLines as well.

[Nuluvius]

7 hours ago, Erik Sieghart said:

I don't like this use of var; it's actually a case where it has highly discouraged use. It's not immediately apparent to the reader what type line is, especially when other methods are tacked on. In the future I'd avoid using var like this. Really only use it in cases where it creates more readable code (usually in instantiation statements).

Let's be clear that this is your opinion. Ultimately keeping consistency with codebase style is most important. That said in my experience the standard has been to use var. Moreover I think that it is perfectly declarative and readable even here; are you saying that you are too lazy to hover your mouse over the keyword to find out? Or are you saying that it's just a lack of experience that you don't immediately know what type should be expected that causes you to pollute your code thus?

[Yamoto42]

4 hours ago, Nuluvius said:

 are you saying that you are too lazy to hover your mouse over the keyword to find out?

On the other hand, it could be argued that in fact you are too lazy to (or maybe it's just " lack of experience") know what type is returned and thusly have to have the compiler figure it out for you.

Let's try not to insult people for stylistic differences.

[Nuluvius]

3 minutes ago, Yamoto42 said:

On the other hand, it could be argued that in fact you are too lazy to (or maybe it's just " lack of experience") know what type is returned and thusly have to have the compiler figure it out for you.

Let's try not to insult people for stylistic differences.

If one is struggling to understand/read code then that code is invariably badly written or badly designed or the problem lies instead with the individual's experience/competence. This is irrespective of what keywords and/or constructs have been used.

 

Why waste time typing out all of that unnecessary guff and using up all of that unnecessary space when the language has a feature to take care of it for you? I'd posit that it's then down the the individual to be able to understand and use that feature properly.

[Yamoto42]

2 minutes ago, Nuluvius said:

If one is struggling to understand/read code then that code is invariably badly written or badly designed or the problem lies instead with the individual's experience/competence. This is irrespective of what keywords and/or constructs have been used.

 

Why waste time typing out all of that unnecessary guff and using up all of that unnecessary space when the language has a feature to take care of it for you? I'd posit that it's then down the the individual to be able to understand and use that feature properly.

This, I agree with.  You original wording on an educational section of a forum...not so much.

 

I do personally prefer to err on the side of using it less often, but with a background largely in C and embedded stuff I personally prefer to be as explicit as possible about what I intend.  Ultimately it's about consistency with the rest of the code base though.

But then again, I am also the kind of jackass that likes to call people out for being jackasses.

[Nuluvius]

8 hours ago, Erik Sieghart said:

My opinion is consistent with the official C# Coding Conventions.

That's fine however it is still subjective. Did you miss that very first line?

Quote

The C# Language Specification does not define a coding standard. However, the guidelines in this topic are used by Microsoft to develop samples and documentation.

8 hours ago, Erik Sieghart said:

This is the style guide you'll find is used by the vast majority of .NET developers. 

I think that you'll find that once you get out and spend some time in the real world it's a bit different than the idealized version that you may have been lead to imagine.

8 hours ago, Erik Sieghart said:

Your code could also be improved to

That's nice but as it happens I'd copy pasted it from a SO post (I probably spend ~5 seconds doing so) so if pedanticism is something that's especially important to you then perhaps you should go make that comment over there as well.

8 hours ago, Erik Sieghart said:

I hear this comment all of the time from people who attempt to defend their poor coding practices as a difference in competence.

If you are hearing it 'all the time' then perhaps there may be some point in listening to it:

8 hours ago, Erik Sieghart said:

It's not immediately clear you're returning a string, and appending string in front of line is objectively clearer than using var. Your code creates an IEnumerable<string> and then invokes methods on it which happen to return a string. I think that's a dangerous habit to get into, and I don't want any new developer to get into bad habits. I often found styling my code to be difficult at first, so I like to spend the extra time to explain why I styled it the way I did.

This is not poor coding practice this is poor fundamental understanding of the language. All of that syntactic sugar does indeed hide some very dangerous things and one should know exactly what it means on a fundamental level before they go trying to implement with it. The problem is simply more insidious than trying to lay blame on a keyword or excusing it as poor habit; the only poor habit that I can see here is ignorance!