Ve Firefoxu bude lepší správa profilů (oddělené nastavení domovské stránky, nastavení lišt, instalace rozšíření, uložení hesla, přidání záložky atd.). Nový grafický správce profilů bude postupně zaváděn od 14.října.
Canonical vydal (email) Ubuntu 25.10 Questing Quokka. Přehled novinek v poznámkách k vydání. Jedná se o průběžné vydání s podporou 9 měsíců, tj. do července 2026.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzi 1.5.0.
Byla vydána nová verze 1.12.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace.
V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).
Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.
Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.
Google postupně zpřístupňuje českým uživatelům Režim AI (AI Mode), tj. nový režim vyhledávání založený na umělé inteligenci. Režim AI nabízí pokročilé uvažování, multimodalitu a možnost prozkoumat jakékoliv téma do hloubky pomocí dodatečných dotazů a užitečných odkazů na weby.
Programovací jazyk Python byl vydán v nové major verzi 3.14.0. Podrobný přehled novinek v aktualizované dokumentaci.
Bylo oznámeno, že Qualcomm kupuje Arduino. Současně byla představena nová deska Arduino UNO Q se dvěma čipy: MPU Qualcomm Dragonwing QRB2210, na kterém může běžet Linux, a MCU STM32U585 a vývojové prostředí Arduino App Lab.
class SomeClass : public SomeParent { private: const float PI = 3.14; int someValue = -1; public: SomeClass(int someValue) : someValue(someValue) { } int SomeValue() { return someValue; } // getter bez prefixu ako v Qt int SetSomeValue(int value) { someValue = value; } // setter s prefixom std::optional<int> PositiveNumber() { return ( someValue >= 0 ? std::optional(someValue) : std::nullopt ); } };ternárny operátor je buď tak ako vidíte vyššie, alebo vetvy zalamujem ešte do nového riadku, v prípade že je tam toho viac (zvyk z React-u)
return ( someValue >= 0 ? std::optional(someValue) : std::nullopt );Metódu PositiveNumber by som za normálnych okolností oddelil a presunul do implementačného súboru, lenže inokedy to za mňa robí VisualAssist, ktorý v textare-e na abclinuxu nemáme a ručne sa mi to deliť nechce. Vymyslel som to asi zaujímavo, ale ako vždy nie som so svojim nápadom spokojný... Lebo čím ďalej, tým viac mi vadí nekonzistencia medzi STL / boostom a mojimi projektami. Preto som sa rozdol, že formátovanie a odsadzovanie kódu a tiež konvencie pre gettery a settery zachovám, ale názvy všetkých identifikátorov prekopem do snake_case: všetko vrátane typov a tried bude malými písmenami (presne ako to má STL). Dôvodov mám viac.
Tiskni
Sdílej:
O tom se snad nemusí diskutovat, ne? :-) Jasně, že tabulátory.
misto tabu čtyry mezery!!!!!! :O :O :D :D ;D ;D
btw tišnovskej pro tebe asi jako nabýtku která se nevodmítá sem si všimla hele :O :O :D ;D
Je rok 2020. Proste v editoru nastavim, co se ma stat, kdyz zmacknu tabulator/backspace a je mi to uplne jedno, jakou vypln to tam nakonec vklada.To bych řek, že je spíš taknějak circa 2010. 2020 řešení je psát do editoru úplně cokoli a pak akorát zmáčknout klávesovou zkratku nebo příkaz, co vyvolá formatter. Občas když rychle dělám nějakej menší refaktor, to naprasim do editoru nějak hlava nehlava jen do tý míry, aby byla korektní syntaxe a pak jen nechám zformátovat do pěkného vzhledu automaticky...
2020 řešení je psát do editoru úplně cokoli a pak akorát zmáčknout klávesovou zkratku nebo příkaz, co vyvolá formatter.
Tohle používám u vlastních nebo nových projektů.
Pokud ale upravuješ nějakou starou věc a máš tam udělat třeba jen nějakou drobnou změnu, tak tohle opravdu není cesta. Za přeformátování celého kódu by ti ten, kdo ti bude dělat revizi kódu nebo později hledat něco v historii či dělat merge, nepoděkoval.
2020 řešení je psát do editoru úplně cokoli a pak akorát zmáčknout klávesovou zkratku nebo příkaz, co vyvolá formatter.Takze preformatujes cely soubor... To teda dekuju. Kdybys tohle udelal na projektu kde pracuju tak bych te hnal svinskym krokem
Je rok 2020. Proste v editoru nastavim, co se ma stat, kdyz zmacknu tabulator/backspace a je mi to uplne jedno, jakou vypln to tam nakonec vklada. Pracuje se s tim stejne.
A jak řešíš zarovnávání? Pokud máš tvrdý limit na délku řádku a metodu s více parametry, tak se tomu nedá vyhnout.
?
pouze mezery (pro odsazení i zarovnání)Tohle je IMO lepší jednak protože to je jednoduchý a jednak protože v terminálu a na webu se tab typicky zobrazuje se šířkou 8, což je IMO moc. (Ano, teoreticky a někdy i prakticky se to dá přenastavit, ale to lidi typicky nedělaj.)
Výhoda tabulátorů je právě v tom, že si lidi můžou nastavit jeho šířku. Obecně mají lidé různé preference a jedna velikost nevyhovuje všem. Někomu se čte líp text odsazený na šířku dvou mezer, někomu čtyř, někomu osm… Potkal jsem i exoty, kterým vyhovovala šířka odsazení 3 nebo 6. Když ale používáš tabulátory (+ případně mezery pro zarovnání), tak tě tyto odlišnosti nemusí trápit a není potřeba se hádat, jestli je lepší 3, 4, 6, 8 nebo jiné číslo.
Zrovna ta šířka 8, která se ti zdá moc, pochází od skupiny lidí, kteří argumentují tím, že když koukáš dvacet hodin do kódu, tak máš unavené oči a takto široké odsazení ti pomůže se v tom ḱódu neztratit. Já nemám potřebu to nikomu rozmlouvat, osobně mi vyhovuje šířka 4, ale když chce někdo 8, tak ať má 8, nemám s tím problém. Případně někteří tvrdí, že větší odsazení tě podvědomě nutí se krotit co se týče zanoření metod/podmínek/cyklů/…
nóó ale mezery a taby sou proporcionálně stejně zvěčený jako celej font takže to je jakoby jedno ne?????? :O :O
Já myslím, že není tak úplně pravda, že:
Nobody talks about the real reason to use Tabs over Spaces
podle mého to spadá pod ty osobní preference. To, že někdo třeba hůř vidí, může mít vliv na to, že preferuje takové a takové osazení.
Ale asi neškodí tenhle důvod/případ zmínit explicitně.
Ta nejednotnost může mít i výhody: na první pohled vidíš, jestli je to tvůj kód nebo kód knihovny/frameworku – např. mojeMetoda()
vs. jejich_metoda()
. Jasně, že člověk nebude svůj kód formátovat schválně jinak, ale je to pozitivní vedlejší efekt, pokud taková konstelace nastane.
{
tolik rušivé po vypsání grepem.
void foo(void) { if (něco) { /* … */ } } void bar(void) { /* … */ }
foo.bar.baz.UsefulApi
, kde ale tohle je pouze vnitřní (privátní) organizace a navenek je to exportováno zjednodušeně* jako foo.UsefulApi
.
*) Bez implementačních detailů, bez nutnosti exponovat vnitřní strukturu, která se může měnit...
Je taky případně možné přejmenovat / vytvořit alias pro externí dependenci?
Hmm. Jak je to vlastně v Javě s aliasy/re-exporty? Umí něco takového? Mám tim na mysli to, že vnitřní a vnější namespace struktura nějaké knihovny je jiná.
V Javě je to úplně jednoduché – struktura „vnějších“ a „vnitřních“ jmenných prostorů je stejná. Občas by se hodilo to, co můžeš dělat např. v C++ pomocí using
, ale zase je to takové nezáludné a přímočaré.
Bez implementačních detailů, bez nutnosti exponovat vnitřní strukturu, která se může měnit...
Tohle je běžná věc, ale používají se k tomu rozhraní. Exportuješ např. com.example.kralyk.Abc
a implementace (vracená třeba z nějaké továrny) bude v jedné verzi com.example.kralyk.impl.bla.bla.HyperAbc
a v jiné com.example.kralyk.impl.foo.bar.TurboAbc
a uživatel ty interní názvy a interní jmenné prostory vůbec nemusí řešit resp. ani je nevidí, pokud vyloženě nechce (přes reflexi). Ve zdrojovém kódu by se na ty implementace ani neměl dostat, protože by měl záviset jen na balíčku s rozhraním. Případně třeba v OSGi bys mohl mít rozhraní i implementaci v jednom balíčku, ale exportované by bylo jen rozhraní, nikoli implementace.
Je taky případně možné přejmenovat / vytvořit alias pro externí dependenci?
Pomocí Mavenu si můžeš „přebalit“ knihovnu a mj. přejmenovat jmenné prostory. Viz Relocating Classes. Ale to jsem snad reálně ani nikde nepoužil.
Tohle je běžná věc, ale používají se k tomu rozhraní.Ok, jenom pro úplnost dodám (asi to už víš), že tohle by nešlo použít pro POD/hodnotové typy, staticky dispatchované typy apod., ale tyhle věci v Javě nejsou, takže tam to není problém...
Třeba v C/C++ bys tyhle struktury nebo definice funkcí dal do hlavičkového souboru a ten bys sdílel mezi klientem a jednotlivými implementacemi, ne?
Tohle mají IMHO hezky udělané v SQLite. Tedy hezky v rámci možností céčka :-) Modul implementující rozhraní pak ani nezávisí na dynamické knihovně jádra – jen v době kompilace závisí na tom hlavičkovém souboru.
Třeba v C/C++ bys tyhle struktury nebo definice funkcí dal do hlavičkového souboru a ten bys sdílel mezi klientem a jednotlivými implementacemi, ne?Záleží, je to škála. Ten příklad s těmi SQLite pluginy je jeden konec té škály, kde je maximální oddělení. Počítám, že ty pluginy se dokonce načítají nejspíš nějakým
dlopen()
. Na druhém konci té škály je kód, kde je potřeba těsná vazba např. kvůli výkonu a/nebo používá hodně templates.
public: SomeClass(int someValue) : return ( someValue >= 0 ? std::optional(someValue)Niekde máš medzeru, niekde nie, ja by som napísal:
public: SomeClass (int someValue): return ( someValue >= 0 ? std::optional (someValue)
if (...)
return (...)
funkce(...)
sice vypada syntakticky podobne ale semanticky je to neco jineho... Neni duvod to psat vse stejne a spis je duvod to odlisit FORMAT C: