07-20-2023, 05:07 AM
**TLDR**
1. If framework is called **AEConicalGradient**, should classes in it be called **ConicalGradientLayer** and **ConicalGradientView** or just **Layer** and **View**?
2. If framework is called **AELog**, and it has class also called **AELog** and other class called **Line** with some delegate callback which is using this **Line** type, how to implement this delegate if your code also has defined type called **Line**, because adding framework name as a prefix in method signature `func didLog(line: AELog.Line)` will make error `'Line' is not a member type of 'AELog'` which in fact it isn't (it's part of **AELog framework**, but it's not member of **AELog class** inside of it).
**Read More**
While updating several frameworks of mine for Swift 3 I was having a lot of second thoughts about what's the proper naming convention for framework classes depending on framework name itself.
In the end I realized that I didn't really used same convention across different frameworks, so now I don't like this lack of consistency.
I'll jump straight into some real-world examples which I encountered:
**1. Example: Framework doesn't have a class named as framework name:**
Framework is named **AEConicalGradient** and it consists of 2 public classes:
- CALayer subclass
- UIView subclass
What should be proper name for each of these classes?
a) **AEConicalGradientLayer** and **AEConicalGradientView**
b) **ConicalGradientLayer** and **ConicalGradientView**
c) **Layer** and **View**
**Discussion:**
a) *I used this in the first version of framework with both of these classes in single **AEConicalGradient.swift** file. I don't like this approach anymore, I'm separating sources into multiple files so now I'm thinking between **b)** and **c)** approaches.*
b) *In this approach I like the fact that someone can just drag these files into project (e.g. without using any dependency manager) or copy/paste code and it wouldn't loose context too much (because of clear names), but on the other side it sounds a little bit repetitive if you think of it as **AEConicalGradient.ConicalGradientLayer** and **AEConicalGradient.ConicalGradientView**.*
c) ***AEConicalGradient.Layer** and **AEConicalGradient.View** sounds like the way I want it, but on the other side those are more likely to make a conflict if someone has their own **Layer** or **View** classes, or if they just drag files or copy/paste code context is pretty much lost (like what is this **Layer** or **View** class for?).*
**2. Example: Framework does have a class named as framework name:**
Framework is named **AELog** and it consists of 3 public classes and a delegate protocol:
- Shared Instance (and delegate for it)
- Log Line model
- Config
**Discussion:**
a) *Similar to the first example in the first version of framework I had classes named **AELog**, **AELogDelegate**, **AELogLine** and **AELogConfig** - all inside single **AELog.swift** file.*
b) *In the latest update for Swift 3 I ended up with multiple files and class names: **AELog**, **AELogDelegate**, **Line** and **Config**.*
*That's when I realized that if you `import AELog` and implement `AELogDelegate` (which has only `func didLog(line: Line)`) AND you already have a different `Line` class defined in your own module **it will make a conflict which can be solved only by renaming one of those two `Line` classes!***
*To be honest, I don't really understand how to avoid this. Because if you try to namespace type in delegate method like `func didLog(line: AELog.Line)` you'll get error `'Line' is not a member type of 'AELog'` which in fact it isn't (it's part of **AELog framework**, but it's not member of **AELog class** inside of it).*
*That's when I started to feel a bit concerned on this "loose" naming. Any suggestions or opinions on this specific matter?*
c) *In the spirit of very "loose" naming like in **1.c)** approach, is it ok to rename **AELog** class to just **Log**, and **AELogDelegate** to just **Delegate**? Would this fix error stated in **2.b)** because there's no class named same as framework name so maybe compiler would recognize **AELog.Line** in that case?*
**Question:**
What are some "clean code" arguments on either of these approaches? Is there an obvious "proper" way on how it should be done? Am I missing something important here?
1. If framework is called **AEConicalGradient**, should classes in it be called **ConicalGradientLayer** and **ConicalGradientView** or just **Layer** and **View**?
2. If framework is called **AELog**, and it has class also called **AELog** and other class called **Line** with some delegate callback which is using this **Line** type, how to implement this delegate if your code also has defined type called **Line**, because adding framework name as a prefix in method signature `func didLog(line: AELog.Line)` will make error `'Line' is not a member type of 'AELog'` which in fact it isn't (it's part of **AELog framework**, but it's not member of **AELog class** inside of it).
**Read More**
While updating several frameworks of mine for Swift 3 I was having a lot of second thoughts about what's the proper naming convention for framework classes depending on framework name itself.
In the end I realized that I didn't really used same convention across different frameworks, so now I don't like this lack of consistency.
I'll jump straight into some real-world examples which I encountered:
**1. Example: Framework doesn't have a class named as framework name:**
Framework is named **AEConicalGradient** and it consists of 2 public classes:
- CALayer subclass
- UIView subclass
What should be proper name for each of these classes?
a) **AEConicalGradientLayer** and **AEConicalGradientView**
b) **ConicalGradientLayer** and **ConicalGradientView**
c) **Layer** and **View**
**Discussion:**
a) *I used this in the first version of framework with both of these classes in single **AEConicalGradient.swift** file. I don't like this approach anymore, I'm separating sources into multiple files so now I'm thinking between **b)** and **c)** approaches.*
b) *In this approach I like the fact that someone can just drag these files into project (e.g. without using any dependency manager) or copy/paste code and it wouldn't loose context too much (because of clear names), but on the other side it sounds a little bit repetitive if you think of it as **AEConicalGradient.ConicalGradientLayer** and **AEConicalGradient.ConicalGradientView**.*
c) ***AEConicalGradient.Layer** and **AEConicalGradient.View** sounds like the way I want it, but on the other side those are more likely to make a conflict if someone has their own **Layer** or **View** classes, or if they just drag files or copy/paste code context is pretty much lost (like what is this **Layer** or **View** class for?).*
**2. Example: Framework does have a class named as framework name:**
Framework is named **AELog** and it consists of 3 public classes and a delegate protocol:
- Shared Instance (and delegate for it)
- Log Line model
- Config
**Discussion:**
a) *Similar to the first example in the first version of framework I had classes named **AELog**, **AELogDelegate**, **AELogLine** and **AELogConfig** - all inside single **AELog.swift** file.*
b) *In the latest update for Swift 3 I ended up with multiple files and class names: **AELog**, **AELogDelegate**, **Line** and **Config**.*
*That's when I realized that if you `import AELog` and implement `AELogDelegate` (which has only `func didLog(line: Line)`) AND you already have a different `Line` class defined in your own module **it will make a conflict which can be solved only by renaming one of those two `Line` classes!***
*To be honest, I don't really understand how to avoid this. Because if you try to namespace type in delegate method like `func didLog(line: AELog.Line)` you'll get error `'Line' is not a member type of 'AELog'` which in fact it isn't (it's part of **AELog framework**, but it's not member of **AELog class** inside of it).*
*That's when I started to feel a bit concerned on this "loose" naming. Any suggestions or opinions on this specific matter?*
c) *In the spirit of very "loose" naming like in **1.c)** approach, is it ok to rename **AELog** class to just **Log**, and **AELogDelegate** to just **Delegate**? Would this fix error stated in **2.b)** because there's no class named same as framework name so maybe compiler would recognize **AELog.Line** in that case?*
**Question:**
What are some "clean code" arguments on either of these approaches? Is there an obvious "proper" way on how it should be done? Am I missing something important here?