Return to Answer

Although this is just a small example, there are some lessons that assume greater importance when you are writing bigger programs. The two guidelines I wish to promote are: ###Separate the definitions from the logic In your function, the knowledge of which characters are classed as vowels is buried deep inside. It's often better to use a data structure (perhaps just a list or an array) to hold that knowledge, and then use that from your function. There are two benefits:

1. Somebody reading your code for the first time can see, early in the file, the data you'll be using. They will find it much easier to add missing vowels such as ố if there's just one obvious place to do so.
2. When you decide that you want to treat w and y (and ŵ) as vowels when the input is in Welsh, but not for English input, you can pass a different data table into the function depending on the language.

As an aside, we should note that toLower is not exactly equivalent to a case-insensitive comparison in many locales.

###Separate processing from I/O It's hard to unit-test your code, because the reading and writing are done in the same function as the processing. If you write the processing as a function, you can write a main() that repeatedly tests that function with known inputs and expected outputs.

(You might be able to tell that I'm not fluent in C#; that's why I'm not providing code samples to back up my advice)

Although this is just a small example, there are some lessons that assume greater importance when you are writing bigger programs. The two guidelines I wish to promote are:

Separate the definitions from the logic

In your function, the knowledge of which characters are classed as vowels is buried deep inside. It's often better to use a data structure (perhaps just a list or an array) to hold that knowledge, and then use that from your function. There are two benefits:

1. Somebody reading your code for the first time can see, early in the file, the data you'll be using. They will find it much easier to add missing vowels such as ố if there's just one obvious place to do so.

2. When you decide that you want to treat w and y (and ŵ) as vowels when the input is in Welsh, but not for English input, you can pass a different data table into the function depending on the language.

   As an aside, we should note that toLower is not exactly equivalent to a case-insensitive comparison in many locales.

Separate processing from I/O

It's hard to unit-test your code, because the reading and writing are done in the same function as the processing. If you write the processing as a function, you can write a main() that repeatedly tests that function with known inputs and expected outputs.

(You might be able to tell that I'm not fluent in C#; that's why I'm not providing code samples to back up my advice)

Although this is just a small example, there are some lessons that assume greater importance when you are writing bigger programs. The two guidelines I wish to promote are: ###Separate the definitions from the logic In your function, the knowledge of which characters are classed as vowels is buried deep inside. It's often better to use a data structure (perhaps just a list or an array) to hold that knowledge, and then use that from your function. There are two benefits:

1. Somebody reading your code for the first time can see, early in the file, the data you'll be using. They will find it much easier to add missing vowels such as ố if there's just one obvious place to do so.
2. When you decide that you want to treat w and y (and ŵ) as vowels when the input is in Welsh, but not for English input, you can pass a different data table into the function depending on the language.

As an aside, we should note that toLower is not exactly equivalent to a case-insensitive comparison in many locales.

###Separate processing from I/O It's hard to unit-test your code, because the reading and writing are done in the same function as the processing. If you write the processing as a function, you can write a main() that repeatedly tests that function with known inputs and expected outputs.

Although this is just a small example, there are some lessons that assume greater importance when you are writing bigger programs. The two guidelines I wish to promote are: ###Separate the definitions from the logic In your function, the knowledge of which characters are classed as vowels is buried deep inside. It's often better to use a data structure (perhaps just a list or an array) to hold that knowledge, and then use that from your function. There are two benefits:

1. Somebody reading your code for the first time can see, early in the file, the data you'll be using. They will find it much easier to add missing vowels such as ố if there's just one obvious place to do so.
2. When you decide that you want to treat w and y (and ŵ) as vowels when the input is in Welsh, but not for English input, you can pass a different data table into the function depending on the language.

As an aside, we should note that toLower is not exactly equivalent to a case-insensitive comparison in many locales.

###Separate processing from I/O It's hard to unit-test your code, because the reading and writing are done in the same function as the processing. If you write the processing as a function, you can write a main() that repeatedly tests that function with known inputs and expected outputs.

(You might be able to tell that I'm not fluent in C#; that's why I'm not providing code samples to back up my advice)