True story, I know someone who’s from C# background and I’m looking at swift code that looks like this all the time T_T:
class SomeName
{
private var _variableName : String!;
private var _optionalName : SomeType?;
func notAnInitializer()
{
_variableName = "ugly code";
if _optionalName != nil
{
_optionalName!.doSomething();
}
else
{
_optionalName = SomeType();
_optionalName!.doSomething();
}
}
}
This is embarrassing and ugly.
I’d rewrite this to:
class SomeName {
private var _variableName: String
private var _optionalName: SomeType?
func notAnInitializer() {
self._variableName = "ugly code"
if self._optionalName == nil {
self._optionalName = SomeType()
}
self._optionalName?.doSomething()
}
}
My personal preference is to leave an empty line at the top (for readability from my personal prospective) and I do prefer self. for clarity what I’m accessing and from where it comes from.
···
--
Adrian Zubarev
Sent with Airmail
Am 22. Juni 2016 um 17:21:49, Charlie Monroe (charlie@charliemonroe.net) schrieb:
On Jun 22, 2016, at 5:07 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 22, 2016, at 8:36 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
I’d love to see something like this happen to Xcode. I’m curious if we could write an extension for Xcode 8 to refactor code to at least some of the conventions.
I don't believe these rules have a place in the API guidelines
No, not API guidelines per se, but code-style guidelines. I think for the sake of a more unified code-style, given the team's strong position on not allowing any language dialects, I'd suggest something like this being put together. (Yes, I understand that a language dialect is something different, but the point is that there is a strong feeling about a unified languaged.)
When you look at various code in ObjC (StackOverfow, Github), the code styles vary incredibly and it's a mess, looking at some code gives you a headache because it is obvious that the person who wrote it came from C# environment. Yes, it's up to the project's team to decide on some minor things (e.g. whether to go by the 80-char per line limit, use explicit self, etc.), but the major things, such as placement of brackets, colons, spaces between them, etc. should be standardized.
Because currently, as Ben has pointed out, the standard library has a different code-style than the Swift Programming Language or the WWDC presentation and it will diversify over the time.
I kind of really like what Microsoft has done with C# - their coding conventions are out there, clear and precise.
You may ask why would one care? Aside from me being kind of a nitpicker in this area, this is nice when you share code between projects - you have a single code-style even if you share the code.
, which are meant to address how Swifty APIs should be constructed for consumption. Style rules are best addressed by in-house style guides. I've personally adopted left-magnetic colons. This follows the Docs team style. The stdlib folk appear to use floating colons for protocol conformance.
As for Xcode, the new code editor extensions provide exactly this kind of functionality.
-- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution