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 ([email protected])
schrieb:
On Jun 22, 2016, at 5:07 PM, Erica Sadun via swift-evolution
<[email protected]> wrote:
On Jun 22, 2016, at 8:36 AM, Adrian Zubarev via swift-evolution
<[email protected]> 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.
https://msdn.microsoft.com/en-us/library/ff926074.aspx?f=255&MSPPError=-2147217396
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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
