Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code style and "rules" #11

Open
oneofmanylukes opened this issue Jul 22, 2019 · 3 comments
Open

Code style and "rules" #11

oneofmanylukes opened this issue Jul 22, 2019 · 3 comments

Comments

@oneofmanylukes
Copy link
Contributor

I just wanted to know if we can all agree to a code style? Like naming conventions, indentation and such? So I'm just gonna throw this into here, correct me if I'm wrong.

Personally I'm completely with the underscore for class members. But I would suggest that we go with the fashion of guard clauses insted of nesting many if statements into eachother. In addition functions should only have one return if possible. Also what about the use of break and continue? And so on...
I hope you get what I mean

@andrewyancey
Copy link
Owner

I typically try to follow microsoft guidelines, and the "clean code" style as much as I can. I think the exception is the underscore, which I actually think microsoft says not to do, but I like it because _something = something makes sense without having to apply too much thought into another name for something so simple.

For class layout this is what I try to follow (I'm not sure how strict I have been about it tbh):

http://stylecop.soyuz5.com/SA1201.html

For casing I try to follow this:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions

I agree functions should only return one thing (and do one thing). So if you are having trouble making a method only return one thing it's usually a good sign that either A. your method is doing more than one thing, or B. you need to make a new class and the data returned should be in that class. There are edge cases though sometimes.

My opinion on break, and continue is that you should avoid using them, but when you do you should do so in a manner that is easily readable. I would recommend adding comments in that circumstance. The fact is that working with images you do have to keep performance in mind, and break and continue can definitely aid in that.

I like the idea of guard clauses but I've never used them before so I don't think I'd be able to implement them properly without some practice first, but I'm all for using them.

@oneofmanylukes
Copy link
Contributor Author

The other way to name member variables could be m_something but I can't recall where I got this from.

The class layout seems alright so I'll try to follow it as good as possible.

What I meant with the return was that functions should idealy look something like:

public Color GetRandomColor()
{
    Color c = new Color();
    int randomNumber = GetRandomNumber(1, 2);

    switch (randomNumber)
    {
        case 1:
            c = Color.FromArgb(1, 1, 1, 1);
            break;
        case 2:
            c = Color.FromArgb(2, 2, 2, 2);
            break;
        default:
            break;
    }

    return c;
}

and not like:

public Color GetRandomColor()
{
    int random = GetRandomNumber(1, 2);
    switch (random)
    {
        case 1:
            return Color.FromArgb(1, 1, 1, 1);
        case 2:
            return Color.FromArgb(2, 2, 2, 2);
        default:
            break;
    }
    return Color.FromArgb(3, 3, 3, 3);
}

Hope this shows what I meant.

@andrewyancey
Copy link
Owner

I’ve seen the m_ too. I prefer to just use a single underscore, but it’s a group decision.

I get what you mean. Not sure how I feel about it though. Is that common?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants