LibreOffice Coverity Defect Density 0,00

 ( trey | 2014. december 1., hétfő - 13:42 )

A Coverity szerint a The Document Foundation által karbantartott LibreOffice kódja példaértékű abból a szempontból, hogy egyike azoknak, amelyek a legkisebb hibasűrűséggel rendelkeznek. Köszönhető ez annak, hogy a közösség intenzív elemzés alá vetette a kódbázist és javította a talált hibákat.

A 2013 Coverity Scan Open Source Report még arról számolt be, hogy az 1 millió kódsornál többől álló nyílt forrású projektek átlagos hibasűrűsége 0,65. A LibreOffice-hoz hasonló méretű proprietary szoftvereknél ez az érték 0,71.

A LibreOffice az OpenOffice.org kódját forkolta 2010-ben. Kezdetben a LibreOffice sem büszkélkedhetett kiváló eredményekkel, hiszen 1,1-es értékről indult. A LibreOffice csapat több mint 9 millió kódsort elemzett és több mint 10 ezer hibát javított. A Coverity által biztosított adatok alapján a munkát a Red Hat-es Caolán McNamara és csapata végezte.

Caolán McNamara pénteken bejelentette, hogy a LibreOffice kódjának hibasűrűsége 0,00.

Természetesen ez nem jelenti azt, hogy a LibreOffice hibamentes. Simon Phipps szerint ez azt jelenti, hogy a LibreOffice-nál a tesztelés és hibakeresés valószínűleg minden más nyílt forrású projektnél nagyobb hangsúlyt kap.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"Nincs egeszseges ember, csak rosszul kivizsgalt beteg."

A stable, 4.2-es Libreoffice Most Annoying Bugok listája az EOL elérésének pillanatában:
https://bugs.freedesktop.org/show_bug.cgi?id=65675#c235

85 darab. És ez csak a most annoying.

Nagyon praktikus, hogy a LibreOffice híreknél szépen be lehet tag-elni a HUPper-ben az embereket, hogy a máshol felbukkanó hozzászólásaik is könnyebb legyen értelmezni :D

Egyébként ha már muszáj hozzá szólnod (mert gondolom, muszáj), akkor esetleg megpróbálhatnál valami ontopic-ot...

ne izgulj, teged is mar megjeloltunk fossharcoskent, valassz kedvenc szint! ;-)

szerintem arra verni, hogy a coverity szerint 0.00 az index, az edeskeves mindaddig, amig alap dolgok nem/szarul mukodnek (megnezted a listat?)
lehet arra verni, hogy ingyen van, de ettol nem lesz jobb. egy normalis office utan kiver a viz, ha ezt kell hasznalnom, de sajnos muszaj, mert ez a ceges alap. :(

egyeb "ontopic" kerdes?

Szerintem a nagy kéknél az Apache OpenOffice a céges alap vagy ti ez alól is kivétel vagytok? A Libre és Open között is hatalmas a különbség, én boldog lennék ha a Libre Office-t használhatnám bent.

3 eve, mikor imageltem a gepet (mert mi nem a hivatalos imaget futtatjuk, en pl ubuntu 14.04-et, van sok debianos arc is), meg biztos libre volt a hivatalos, ha azota valtozott is, ez a hir nem jutott el hozzank, annyira pedig nem izgattam magam rajta :-)

Sose volt engedélyezett.. Apache OOO előtt Symphony volt a default.. De amúgy nem mintha ez számítana bármit is..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Legyen akkor ez: #366b9f

Egyébként nem kérdés, hogy a LibreOffice-nak van még tere a fejlődésre :D De ettől még teljesen jól használható. Összehasonlítani nem tudom, mert az MS Office nem fut Linuxon (amit őszintén sajnálok, remélem, hogy az új főnök majd meggondolja), így nagyon régen használtam már (95 felé). Ugyanakkor tudom, hogy te okos vagy és te is pontosan látod, hogy nem erről szól itt ez a cikk. Van annak egy kedves bája, hogy a Coverity valamilyen szoftvere szerint veszélyes hibákat valami fejlesztő szerint kijavították az LO-ban, erre idejön az ember, és mondja, hogy de van benne egy csomó idegesítő funkcionális hiba... Nem erről szól a hír. Akkor minek? Én erre mutattam rá. Bár tudom, hogy te is tudod. Azért nem értem, hogy mit akartál a hozzászólásoddal.

+1

MSO mai napig nem tud UTF8 CSV-ket rendesen kezelni illetve megnyitáskor feldobni egy separator választót mindezt a 21. században.... szemben az LO-val.

Kinek mi a normális/nem normális, erősen szubjektív... LO szidói általában nem fektetnek sosem elég időt, hogy megismerjék rendesen... ott keresik a dolgokat ahol MS-nél megszokták... (KRESZ-ben is benne van, hogy ne szokás alapján vezess, mert van hogy dolgok változnak... aztán lehet kiabálni!)

"MSO mai napig nem tud UTF8 CSV-ket rendesen kezelni"

Tud, csak nem megnyitni kell a csv-t hanem importálni.

Most mondjam, hogy MSO szidói általában nem fektetnek sosem elég időt, hogy megismerjék rendesen?

Tud, csak nem megnyitni kell a csv-t hanem importálni.

Höhöhö, nemá'.
(Ennek egyébként van valami prakitkus oka?)
--
blogom

Ha importálod, akkor kapsz némi beállítási lehetőséget is (separator, kódolást, stb.), megnyitásnál nem.

Ezzel (mármint a működéssel) szembesültem már. A (költői) kérdés az, ha duplaklikkelek egy .cvs filera az explorerben, miért nem dobja fel ezt az ablakot az Office?

--
blogom

Mondjuk azért lássuk be, hogy itt egy istenverte bugot kiismerését kéred számon ;) (Disclaimer: én tudom, hogy így működik, sőt, kopipaszta után a villám izével is lehet, de ez ettől még idegesítő hülyeség)

A kezelni számomra nem csak a megnyitást jelenti, hanem a mentést is!
Amúgy részemről elsősorban a "rendesen" van a hangsúly, hisz konkurens termék (LibreOffice) ezt elfogadhatóan tudja.

Minden esetre menteni az MSO úgy tudom egyáltalán nem tud UTF8 CSV-be...de van néhány workaround rá pl:
1. Unicode txt-be menteni (ami más-más MSO verziónál mást jelent, pl az újaknál UTF16 korábbiaknál UTF8), majd a TAB-ot le kell cserélni pl ;-re ha már MSO CSV -ről beszélünk, s bízni, hogy nincs a szövegbe sehol sem egy kósza TAB.
2. elmenteni CSV-be majd átkonvertálni pl iconv-vel vagy akár LibreOffice-al :-D

Kíváncsiságból, hátha tudsz jobb módszert a fantasztikus MSO-val -thirdparty addon/VB script nélkül- _menteni_ UTF8 CSV-t. Felőlem lehet "export" is, ha az szimpatikusabb :-).

Ha személyeskedve nekem szántad, akkor igen "mondjad azt", de szólok, hogy nem vettem magamra.
Úgy gondolom általában megfelelő időt -néha többet is mint kéne- szánok ilyen jellegű problémák "gúgzálására"... persze az idő relatív, kinek mennyi az "elég"

Excel 2013, most néztem meg neked, de ha gondolod, vieót is csinálhatok róla:

default UTF-8-cal ment, ha a "CSV (Comma delimited)" típust választod mentéskor. Ja, és a gépen a locale en-US, az Excel locale szintén, Office-hoz magyar cuccok nincsenek feltelpítve

A Notepad++ szerint (is) UTF-8 w/o BOM-ról van szó.

ez mit jelent? és mit jelent az, hogy a hibasűrűség 0,71? ennyi soronként van hiba? vagy ennyi hiba van egy sorban? mi számít hibának egyáltalán?

Amit a statikus kódanalizátor annak érzékel. Memória nem felszabadítás, lehetséges null pointer exception, elszálló listák (csak belepakol és nem vesz ki), lehetséges
deadlock, ilyesmi. A logikai hibák ellen nem véd (nem azt csinálja egy függvény, amit kellene, hanem azt, amit a programozó leírt)

1000 sorra ennyi hiba esik. Hiba az, amit a Coverity annak vesz.

>és mit jelent az, hogy a hibasűrűség 0,71? ennyi soronként van hiba?
not sure if trolling or just being libreoffice user
_____________________________
Powered by 1,3,7-trimetilxantin

Ez a 0.00 hibasűrűség kamu. Nem jelenthető ki egy nagyobb programnál, hogy hibamentes. Max csak az, hogy az összes felfedezett hiba javítva van.

Ez eléggé a hibasűrűség definiciójától függ...

Én ezt úgy képzelem el - lehet rosszul -, hogy a mostani "0"-ás értéket elérve, szigorúbbra veszik/állítják a Coverity "beállításait" (mit vegyen/tekintsen hibának), ezáltal ugyan felmehet (!) akár újból 2-3 egész értékre is, de ha megint végigmennek (újbóli nagyon sok munkával), újfent még több hibát kiszűrnek.
Megj.: nem vagyok programozó, matematikus, csak szimpla, de ősrégi felhasználója az OO.o & LO "vonalnak". :-)

Eszerint compiler warningokat sem lehetne sose teljesen kiírtani (mármint nem a warningok kikapcsolásával).

A Coverity és a többi static analyzer ugyanúgy dolgozik, mint egy compiler, csak sokkal több mindenen aggódik, és nincs benne kódgenerátor, csak elemző. Nem azt állítja, hogy nincs benne hiba, hanem azt, hogy nem talál benne. Nagy különbség.

A hír nem arról szól, hogy a LibreOffice hibamentes lenne. (Nekem pl. általában prezentáció közben szokott elszállni a legfrissebb verzió is.)

Arról szól, hogy a Coverity nem talál benne hibát, ami nagy szó, különösen ha figyelembe vesszük, hogy mekkora kódbázisról van szó.

Ez csak bizonyos fajta hibákról mond valamit. Pl., hogy nem fog elszállni a szövegszerkesztő semmilyen dokumentum megnyitása közben. De, hogy azt a dokumentumot jól jeleníti-e meg, vagy pl. hogy képes-e egy cellához megjelenő "comment" ablak eltüntetése után annak a kereteit is eltüntetni (nem, nem képes), arról nem mond semmit ez a bizonyos "Defect Density".

Mint mar fentebb irtak ez a szam nem azt mutatja, hogy tenyleges hiba van-e, hanem csak olyan dolgokat nez "hiba"-kent ami meg van adva az elemzo szoftvernek.

A hibasurusege nem is 0,00. A bejelentesben ott is van, hogy 5,973,881 sor kodot vizsgaltak meg (ami tudtommal nem is a teljes kodbazis) es ennek a hibasurusege 0.003515303 csak hat szeret mindenki kerekiteni es ugy mar mashogy hangzik a dolog. Az elemzo szoftver 11,751 hibat talalt.

Azért ez egy szép dolog szerintem. Lehet, hogy nem lesz ettől kevesebb bug a libreoffice-ban, de mégiscsak egy jó példa arra, hogy lehet opensource alapokon is úgy szoftvert fejleszteni, hogy közben ügyelsz a kódminőségre (aminek nyilván csak egyik aspektusa az, hogy egy static analiser által kiköpött szám egy század alá csökkent).