Diskusia – Mandelbrot v C # WPF, so zoomom a ukladaním obrázkov

Díky za nahrané aplikace. Jsou docela rozumně napsané a máme tu hlavně věci na Windows Forms, takže každé WPFko se cení

Díky. Budu rád za jekékoliv připomínky, náměty ke zlepšení.

Mě to přijde vážně dobré. Vždy se najde pár drobností, ale celek je dobrý. Nemám bohužel prostor ke zkoumání návrhu nebo efektivity implementace, ale co se týká kódu, tak:

• většinou se před privátní atributy stejně píše private, modifikátory není dobré vynechávat, třeba v PHP by to bylo takhle public
• dodržovat nějaké konvence pro názvosloví, třeba metoda PocatecniLimity() by spíš měla být NastavPocatecniLimity(), metody dělají akce, PocatecniLimity je jak název pro vlastnost. Vykresli() a Ulozit() jsou 2 různé konvence, používal bych vždy rozkazovací způsob pro danou akci, tedy Uloz().
• spojovat cesty přes Path.Combine, aby to případně fungovalo i na jiných OS, C# má nějaké porty na Linux a ten nepoužívá zpětná lomítka
• třída Bod by mi dávala smysl spíše jako struktura (struct), ale nevím, jestli na ni nepotřebuješ reference, opravdu to nemohu tak detailně zkoumat
• kód na nastavování těch limitů je dost duplicitní, asi bych udělal nějakou metodu, co by to brala v parametrech a nastavila
• přijde mi trochu matoucí používat třídy Point a Bod

Výše uvedené věci jsou poměrně málo významné, i když ve velkých projektech pak mohou zbytečně prudit

Díky za užitečné podněty, dávají mi smysl.

Osobně už private access modifier taky nepíšu, je to redundantní informace a akorát zabírá místo.

Jednu dobu jsem o tom hodně četl, protože mi to připadalo také zbytečné, ale názory na to jsou poměrně jednotné, modifikátory bys měl psát vždy. Hodně juniorů třeba neví jak funguje internal, není vždy jasné jaký modifikátor se tam dá. Zrovna v C#, když před třídu nenapíšeš public, tak to dělá bordel s public vlastnostmi typu struct. Píše to takovou tu divnou hlášku Inconsistent accessibility.

Já to přebral jako interní konvenci firmy a ti to zase (nejspíš) přebrali od R#. První jsem byl taky proti tomu, pak jsem si zvykl a začal používat i mimo firemní kód. Dát classu public a nebo nechat internal je trošku něco jiného. Já to pravidlo (s vynecháním implicitního private) aplikuji jen na fieldy.

Mám dojem, že fieldy v Javě jsou bez modifikátoru internal, ne private. Tam bys mohl mít s takovou konvencí dost nepříjemností. V C# to asi dělá to co by člověk očekával, ale nesouhlasím s tebou, že je to redundantní informace. Není to žádná informace, v tom je rozdíl, prostě to na první pohled není poznat. Proto se to tam většinou píše explicitně.

Nevím proč do toho pleteš Javu. Java má na classu taky package access modifier a můžeš ho vyjádřit jen tím, že tam žádný nenapíšeš - dost intuitivní. To je úplně stejná diskuze jako "tabs vs spaces", každý by měl radši taby, ale prostě defaultní chování IDE dává v .NETu mezery, tak to lidi používají. Tak jako ti IDE přidává private k nově generovaným věcem. V OS už se dost často definují různé konvence, které jdou právě proti tomuhle základnímu chování a ten kód je o mnoho lepší.

Napsal jsi jen odpověď abys něco napsal, neobsahuje žádné pádné argumenty a otevírá zbytečně další témata, která s tím nesouvisí. Tab nebo mezera ti nezpůsobí, že nevíš na 100% co která část kódu dělá. Diskuzi považuji z mé strany za ukončenou, piš si to jak chceš, to už je tvoje věc.