On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi <alok.gandhi2...@gmail.com>
wrote:

>
> Coming back to some of the points that Ian raised:
>     > Readability is a perfectly valid goal to seek but I
> find maintainability is often overlooked.
>
> IMHO more readable code is more maintainable. Readability goes hand in
> hand with maintainability. In fact, I very much agree that code lasts
> longer than an author and if you write readable code it will be easier to
> read and understand for the people after you are gone and are not available
> to explain why you did what. If by maintainability you meant actually
> extensibility, then it is a completely different aspect.
>

As an aside, I just recently went to a convention, and in one of the talks
the speaker opened with his list of priorities for designing software:

1. Integrity - The software should operate in a predictable manner, respond
appropriately to exceptional conditions, and clean up nicely during a
termination

2. Readability - The intent of the code should be clear

3. Simplicity (has to be justified to be more important than #2)
4. Performance

He basically yelled at us for 10 minutes about the importance of the first
two, and said only when you can prove to me that everything else is
addressed, that you should then look at performance. It was a pretty good
talk.


> > In driving to a solution avoiding the additional markup (as in my
> solution or in json/XML) you've likely put yourself (and too often your
> team after you've left) in a place where you'll need to rewrite the
> function for future feature requests.
>
> If you read my previous posts in this threads, you will see that I clearly
> mentioned that getting input is an administrative logic. In fact, I
> provisioned for it and alluded to Marcus about it. Here's what I wrote:
>
>    - Right in the beginning, we parse the string in a single line,
>    keeping the administrative logic out from the rest of our business code.
>    You can easily replace this single line with whatever parser you want.
>
> This means that the code that is responsible for creating nodes should not
> worry itself with how it is getting the data in, JSON or YAML. And the
> parser, whichever it is, should not worry about what is going to happen to
> data it outputs. any good architecture should take care of this point.
> Making components decoupled and flexible. Good architecture does not only
> apply to huge libraries or big project, it should be given thought to every
> single small quantum of code, a function and even inside parts of a
> function. I did not avoid the input data structure, I simply did not work
> on that part as was not required my Marcus originally. Even then, I
> separated the code so that in my implementation, nowhere it does rely on
> whether I choose JSON or YAML or some other markup. If ten years later,
> somebody wants to use my implementation, with JSON the only change it would
> require is to change the first line of my code.
>
>
>
> On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson <konstrukt...@gmail.com>
> wrote:
>
>> Thanks Ian!
>>
>> Some notes.
>>
>> - The implementation is up for grabs, but I'd like to keep the interface
>> of the function; that is, passing a single string with indentation for
>> hierarchy.
>> - Performance is not important here, because (1) the function is only
>> being used in example code, where the call itself should fall into the
>> background and (2) creating a hierarchy can safely take a few hundred
>> milliseconds if it means more readable code.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to python_inside_maya+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_KwK32ZxRZeo%3DatdrKgdkeThNzRw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_KwK32ZxRZeo%3DatdrKgdkeThNzRw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python_inside_maya+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMT8pNLXc4XM7jT4AVQETE37Q9Z0pGYBBBjYZhYbLDHKMQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMT8pNLXc4XM7jT4AVQETE37Q9Z0pGYBBBjYZhYbLDHKMQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0Sxx%2B2319C1Mv4omtaiEvjppJPrFjVYtgmYxSJvs74AQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to