5 ms·

But Google's code quality is quite high...

• ingsoc79 10y ago
  Have you ever worked with the Android SDK?
  • perfmode 10y ago
    In my opinion, Android's code organization is a result of questionable architectural constraints applied early in the development of the platform.
    • JangoSteve 10y ago
      Isn't that exactly the point roguecoder made? > I have had catastrophic failures caused by premature optimization, because locking a tool into a fancy algorithm before you know where the actual bottleneck is is a recipe for disaster. EDIT: Or, are you saying that it was from the decisions made before Google acquired Android?
• CaptSpify 10y ago
  I think that highly depends on what you value in code.
• korzun 10y ago
  That's a bit biased.
• yawaramin 10y ago
  I don't know about their code quality, but we consume some of their data via APIs and they periodically randomly change their non-nullable data types to nullable. Fun times hotfixing those in prod.
  • perfmode 10y ago
    When data comes in over the wire, you probably shouldn't be making assumptions about what's nullable. You should write a parser that fails gracefully if it receives unexpected input. It's the robustness principle. https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
    • Drdrdrq 10y ago
      You're missing the point. Sure, you should make it fil gracefully on unexpected input. But Google shouldn't change APIs in a way hat causes 3rd party apps to fail at all.
      • perfmode 10y ago
        Third party apps wouldn't fail if they were correct in the first place. Failing gracefully on unexpected input is the way a competent engineer would structure their program.
        • deleted 10y ago
          [deleted]
        • ethbro 10y ago
          Is there a functional difference between "my production code suddenly stopped processing work because it rejected a newly nullable input value" vs "my production code suddenly stopped processing work because it crashed on a newly nullable input value"?
          • protomyth 10y ago
            If the crash gives an attack vector for a security threat then there is. Personally, "Be conservative in what you do, be liberal in what you accept from others" is a bad policy in the modern world. It should be "Be conservative in what you do, be strict as if you don't trust them in what you accept from others".
  • captn3m0 10y ago
    Funny you point this out. Google's JSON Style guidelines[1] say this: >If a property is optional or has an empty or null value, consider dropping the property from the JSON, unless there's a strong semantic reason for its existence. [1]: https://google.github.io/styleguide/jsoncstyleguide.xml?showone=Empty/Null_Property_Values#Empty/Null_Property_Values https://google.github.io/styleguide/jsoncstyleguide.xml?show...
    • perfmode 10y ago
      That's a different issue. The commenter is referring to keys that can take on null. This style guide entry suggests a course of action in the event that one of these keys currently has a null value. The style guide isn't prohibiting nullable keys.
  • walshemj 10y ago
    yes some of their api's and tools are a bit shoddy eg unable to parse a xml sitemap to spec and that spec was only a 3 page RFC!